draft-ietf-rmt-fec-bb-revised-00.txt   draft-ietf-rmt-fec-bb-revised-01.txt 
Reliable Multicast M. Watson Reliable Multicast M. Watson
Internet-Draft M. Luby Internet-Draft M. Luby
Expires: October 31, 2005 Digital Fountain Expires: March 5, 2006 Digital Fountain
L. Vicisano L. Vicisano
Cisco Systems, Inc. Cisco Systems, Inc.
April 29, 2005 September 1, 2005
Forward Error Correction (FEC) Building Block Forward Error Correction (FEC) Building Block
draft-ietf-rmt-fec-bb-revised-00 draft-ietf-rmt-fec-bb-revised-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 31, 2005. This Internet-Draft will expire on March 5, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes how to use Forward Error Correction (FEC) This document describes how to use Forward Error Correction (FEC)
codes to efficiently provide and/or augment reliability for data codes to efficiently provide and/or augment reliability for data
transport. This document defines a framework for the definition of transport. This document defines a framework for the definition of
skipping to change at page 2, line 20 skipping to change at page 2, line 18
those codes and registering them with the Internet Assigned Numbers those codes and registering them with the Internet Assigned Numbers
Authority (IANA) are also described. The requirements on Content Authority (IANA) are also described. The requirements on Content
Delivery Protocols which wish to use FEC codes defined within this Delivery Protocols which wish to use FEC codes defined within this
framework are also defined. The companion document titled, "The Use framework are also defined. The companion document titled, "The Use
of Forward Error Correction (FEC) in Reliable Multicast" describes of Forward Error Correction (FEC) in Reliable Multicast" describes
some applications of FEC codes for delivering content. some applications of FEC codes for delivering content.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 5 2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 4
3. Requirements notation . . . . . . . . . . . . . . . . . . . . 6 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 5
4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 8
6. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1 FEC Schemes . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. FEC Schemes . . . . . . . . . . . . . . . . . . . . . . . 10
6.2 FEC Object Transmission Information . . . . . . . . . . . 13 6.2. FEC Object Transmission Information . . . . . . . . . . . 12
6.2.1 Transport of Object Transmission Information . . . . . 14 6.2.1. Transport of FEC Object Transmission Information . . . 13
6.2.2 Opacity of Object Transmission Information . . . . . . 15 6.2.2. Opacity of FEC Object Transmission Information . . . . 14
6.2.3 Mandatory FEC Object Transmission Information 6.2.3. Mandatory FEC Object Transmission Information
elements . . . . . . . . . . . . . . . . . . . . . . . 15 elements . . . . . . . . . . . . . . . . . . . . . . . 14
6.2.4 Common FEC Object Transmission Information elements . 15 6.2.4. Common FEC Object Transmission Information elements . 15
6.2.5 Scheme-specific FEC Object Transmission 6.2.5. Scheme-specific FEC Object Transmission
Information element . . . . . . . . . . . . . . . . . 16 Information element . . . . . . . . . . . . . . . . . 15
6.3 FEC Payload ID . . . . . . . . . . . . . . . . . . . . . . 16 6.3. FEC Payload ID . . . . . . . . . . . . . . . . . . . . . . 16
7. FEC scheme specifications . . . . . . . . . . . . . . . . . . 18 7. FEC scheme specifications . . . . . . . . . . . . . . . . . . 17
8. CDP specifications . . . . . . . . . . . . . . . . . . . . . . 21 8. CDP specifications . . . . . . . . . . . . . . . . . . . . . . 20
9. Common algorithms . . . . . . . . . . . . . . . . . . . . . . 22 9. Common algorithms . . . . . . . . . . . . . . . . . . . . . . 21
9.1 Block partitioning algorithm . . . . . . . . . . . . . . . 22 9.1. Block partitioning algorithm . . . . . . . . . . . . . . . 21
9.1.1 First Step . . . . . . . . . . . . . . . . . . . . . . 22 9.1.1. First Step . . . . . . . . . . . . . . . . . . . . . . 21
9.1.2 Second step . . . . . . . . . . . . . . . . . . . . . 23 9.1.2. Second step . . . . . . . . . . . . . . . . . . . . . 22
10. Requirements from other building blocks . . . . . . . . . . 25 10. Requirements from other building blocks . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12.1 Explicit IANA Assignment Guidelines . . . . . . . . . . . 27 12.1. Explicit IANA Assignment Guidelines . . . . . . . . . . . 26
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 14.1. Normative References . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . 31 14.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31
1. Introduction 1. Introduction
This document describes how to use Forward Error Correction (FEC) This document describes how to use Forward Error Correction (FEC)
codes to provide support for reliable delivery of content within the codes to provide support for reliable delivery of content within the
context of a Content Delivery Protocol (CDP). This document context of a Content Delivery Protocol (CDP). This document
describes a building block as defined in [11]. This document is a describes a building block as defined in [10]. This document is a
product of the IETF RMT WG and follows the general guidelines product of the IETF RMT WG and follows the general guidelines
provided in [9]. provided in [8].
The purpose of this building block is to define a framework for The purpose of this building block is to define a framework for
forward error correction such that: forward error correction such that:
1. CDPs can be designed to operate with a range of different FEC 1. CDPs can be designed to operate with a range of different FEC
codes/scheme, without needing to know details of the specific FEC codes/scheme, without needing to know details of the specific FEC
code/scheme that may be used code/scheme that may be used
2. FEC schemes can be designed to operate with a range of different 2. FEC schemes can be designed to operate with a range of different
CDPs, without needing to know details of the specific CDPs CDPs, without needing to know details of the specific CDPs
Note that a 'CDP' in the context of this document may consist of Note that a 'CDP' in the context of this document may consist of
several distinct protocol mechanisms. several distinct protocol mechanisms.
Editor's note (to be removed): This document proposes an update to This document also provides detailed guidelines on how to write an
RFC3452. The primary goals of this update are: RFC for an FEC scheme corresponding to a new FEC Encoding ID (for
both Fully-Specified and Under-Specified FEC Schemes).
1. Move the FEC Building Block from Experimental to Proposed
Standard
2. Clarify some confusing language in the current RFC 3452, which
is not incorrect but has been misinterpreted on some occasions
(based on comments on the mailing list and during the RMT
meetings).
3. Provide detailed guidelines on how to write an RFC for an FEC
scheme corresponding to a new FEC Encoding ID (for both Fully-
Specified and Under-Specified FEC Schemes)
4. Ensure that the FEC building block is applicable to multiple
protocols, including FLUTE and NORM. The FEC Building Block
will not preclude the application of FEC Schemes to streaming
protocols, for FEC schemes that support it.
5. Ensure that protocols using this building block can be defined
in a way whch is 'FEC Scheme independent' so that new FEC
schemes can be defined without the need to amend the CDPs.
6. Ensure that new FEC schemes can be defined in a way which is
'CDP independent' so that new CDPs can be defined without the
need to amend the FEC schemes.
7. Ensure on-the-wire backwards compatibility with existing
implementations of protocols that are compliant with the
current Experimental RFCs, e.g., existing implementations of
FLUTE and NORM.
It is anticipated that updates to other RMT RFCs to Proposed
Standard status will be carried out independently and in parallel
with this work. Whilst on-the-wire backwards compatibility is a
mandatory requirement, some reorganisation of material amongst the
RFCs is implied by the approach proposed in this document.
Specifically:
8. FEC Scheme definitions from RFC3452 should be moved to a
separate document. The scheme definitions will be revised to
follow the format specified in this document.
9. FEC scheme specific information in FLUTE (RFC3926) should be
moved into the FEC Scheme specification document referred to
above, for example the formats of the FEC Object Transmission
Information when carried in EXT_FTI.
10. Provision for transport of FEC scheme specific Object
Transmission Information needs to be included in FLUTE and
NORM (in a backwards-compatible way).
It is also proposed that the algorithm for partitioning objects
into source blocks currently included in the FLUTE specification
should be moved into this document as a common algorithm to be
used by multiple FEC Schemes.
2. Definitions/Abbreviations 2. Definitions/Abbreviations
Object: An ordered sequence of bytes to be transferred by the Object: An ordered sequence of bytes to be transferred by the
transport protocol. For example, a file or stream. transport protocol. For example, a file or stream.
Symbol: A unit of data processed by the Forward Error Correction Symbol: A unit of data processed by the Forward Error Correction
code. A symbol is always considered as a unit i.e. it is either code. A symbol is always considered as a unit i.e. it is either
completely received or completely lost. completely received or completely lost.
skipping to change at page 7, line 18 skipping to change at page 6, line 18
provide reliable delivery of an object. Using FEC codes is effective provide reliable delivery of an object. Using FEC codes is effective
in the context of IP multicast and reliable delivery because FEC in the context of IP multicast and reliable delivery because FEC
encoding symbols can be useful to all receivers for reconstructing an encoding symbols can be useful to all receivers for reconstructing an
object even when the receivers have received different encoding object even when the receivers have received different encoding
symbols. Furthermore, FEC codes can ameliorate or even eliminate the symbols. Furthermore, FEC codes can ameliorate or even eliminate the
need for feedback from receivers to senders to request retransmission need for feedback from receivers to senders to request retransmission
of lost packets. of lost packets.
Central to this document is the concept of an 'FEC Scheme'. An FEC Central to this document is the concept of an 'FEC Scheme'. An FEC
scheme defines ancilliary information and procedures which, combined scheme defines ancilliary information and procedures which, combined
with an FEC encoding algorithm, fully define how the FEC code can be with an FEC code specification, fully define how the FEC code can be
used with CDPs. An FEC scheme may be associated with a single used with CDPs. An FEC scheme may be associated with a single
standardised FEC algorithm (A 'Fully specified' FEC scheme) or may be standardised FEC code (A 'Fully-Specified' FEC scheme) or may be
applicable to many FEC algorithms (An 'under-specified' FEC scheme). applicable to many FEC codes (An 'Under-Specified' FEC scheme).
This document describes a framework for the definition of FEC This document describes a framework for the definition of FEC
schemes. Definition of actual FEC schemes is outside the scope of schemes. Definition of actual FEC schemes is outside the scope of
this document. This document also defines requirements for reliable this document. This document also defines requirements for reliable
CDPs that make use of FEC schemes. Any such protocol which is CDPs that make use of FEC schemes. Any such CDP which is compliant
compliant to the requirements specified in this document can make use to the requirements specified in this document can make use of any
of any FEC scheme which is defined within the framework described FEC scheme which is defined within the framework described here.
here. Note that FEC schemes may place restrictions on the types of Note that FEC schemes may place restrictions on the types of CDP they
CDP they are intended to be used with. For example, some FEC schemes are intended to be used with. For example, some FEC schemes may be
may be specific to particular types of application, such as file specific to particular types of application, such as file delivery or
delivery or streaming. streaming.
The goal of the FEC building block is to describe functionality The goal of the FEC building block is to describe functionality
directly related to FEC codes that is common to all reliable CDPs and directly related to FEC codes that is common to all reliable CDPs and
to all FEC schemes, and to leave out any additional functionality to all FEC schemes, and to leave out any additional functionality
that is specific to particular protocols or particular FEC schemes. that is specific to particular CDPs or particular FEC schemes. The
The primary functionality described in this document that is common primary functionality described in this document that is common to
to all such protocols that use FEC codes is the definition and all such CDPs that use FEC codes is the definition and transport of
transport of three kinds of information from sender to receiver(s): three kinds of information from sender to receiver(s): encoding
encoding symbols themselves, anciliary information associated with symbols themselves, anciliary information associated with encoding
encoding symbols (or groups of such symbols, such as the group of symbols (or groups of such symbols, such as the group of symbols in a
symbols in a single packet, or the group of symbols related to a single packet, or the group of symbols related to a single source
single source block) and anciliary information associated with the block) and anciliary information associated with the whole object
whole object being transfered. It is important to note that this being transfered. It is important to note that this ancilliary
ancilliary information is only required by the receiver if one or information is only required by the receiver if one or more of the
more of the encoding symbols to which it relates are received. encoding symbols to which it relates are received.
This document for example does not describe how receivers may request This document for example does not describe how receivers may request
transmission of particular encoding symbols for an object. This is transmission of particular encoding symbols for an object. This is
because although there are protocols where requests for transmission because although there are CDPs where requests for transmission are
are of use, there are also protocols that do not require such of use, there are also CDPs that do not require such requests.
requests.
The companion document [3] should be consulted for a full explanation The companion document [4] should be consulted for a full explanation
of the benefits of using FEC codes for reliable content delivery of the benefits of using FEC codes for reliable content delivery
using IP multicast. FEC codes are also useful in the context of using IP multicast. FEC codes are also useful in the context of
unicast, and thus the scope and applicability of this document is not unicast, and thus the scope and applicability of this document is not
limited to IP multicast. limited to IP multicast.
5. Applicability Statement 5. Applicability Statement
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 multicast protocol MUST provide congestion control. Any complete multicast CDP MUST provide congestion control
control that conforms to [5], and thus this MUST be provided by that conforms to [6], and thus this MUST be provided by another
another building block when the FEC building block is used in a building block when the FEC building block is used in a CDP.
protocol.
A more complete description of the applicability of FEC codes can be A more complete description of the applicability of FEC codes can be
found in the companion document [3]. found in the companion document [4].
6. Functionality 6. Functionality
This section describes FEC information that is either to be sent in This section describes FEC information that is either to be sent in
packets also containing FEC encoding symbols or 'out-of-band'. The packets also containing FEC encoding symbols or 'out-of-band'. The
FEC information is associated with transmission of encoding symbols FEC information is associated with transmission of encoding symbols
related to a particular object. There are three classes of packets related to a particular object. There are three classes of packets
that may contain FEC information: data packets, session-control that may contain FEC information: data packets, session-control
packets and feedback packets. They generally contain different kinds packets and feedback packets. They generally contain different kinds
of FEC information. Note that some protocols may not use session- of FEC information. Note that some CDPs may not use session-control
control or feedback packets. 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 both data and session-control packets generally travel downstream
from the sender towards receivers and are sent to a multicast channel from the sender towards receivers and are sent to a multicast channel
or to a specific receiver using unicast. Session-control packets may or to a specific receiver using unicast. Session-control packets may
additionally travel upstream from receivers to senders. additionally travel upstream from receivers to senders.
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
skipping to change at page 11, line 39 skipping to change at page 10, line 39
b. FEC Payload ID b. FEC Payload ID
CDPs must provide a mechanism for communicating information which CDPs must provide a mechanism for communicating information which
identifies (for FEC purposes) the encoding symbols carried by a identifies (for FEC purposes) the encoding symbols carried by a
packet. This information is known as the FEC Payload ID and its packet. This information is known as the FEC Payload ID and its
contents depend on the FEC scheme. It includes only information contents depend on the FEC scheme. It includes only information
of the second class above. A data packet that carries encoding of the second class above. A data packet that carries encoding
symbols MUST include an FEC Payload ID. symbols MUST include an FEC Payload ID.
6.1 FEC Schemes 6.1. FEC Schemes
Two types of FEC scheme are defined by this document: 'Fully- Two types of FEC scheme are defined by this document: 'Fully-
specified' FEC schemes and 'Under-specified' FEC schemes. An FEC Specified' FEC schemes and 'Under-Specified' FEC schemes. An FEC
scheme is a Fully-Specified FEC scheme if the encoding scheme is scheme is a Fully-Specified FEC scheme if the encoding scheme is
formally and fully specified, in a way that independent implementors formally and Fully-Specified, in a way that independent implementors
can implement both encoder and decoder from a specification that is can implement both encoder and decoder from a specification that is
an IETF RFC. an IETF RFC.
It is possible that an FEC scheme may not be a Fully-Specified FEC It is possible that an FEC scheme may not be a Fully-Specified FEC
scheme, because either a specification is simply not available or a scheme, because either a specification is simply not available or a
party exists that owns the encoding scheme and is not willing to party exists that owns the encoding scheme and is not willing to
disclose the algorithm or specification. We refer to such an FEC disclose the algorithm or specification. We refer to such an FEC
encoding scheme as an Under-Specified FEC scheme. encoding scheme as an Under-Specified FEC scheme.
FEC schemes are identified by an FEC Encoding ID, which is an integer FEC schemes are identified by an FEC Encoding ID, which is an integer
skipping to change at page 12, line 22 skipping to change at page 11, line 21
encoding symbols about different objects, even if transmitted to the encoding symbols about different objects, even if transmitted to the
same set of multicast channels and/or using a single upper-layer same set of multicast channels and/or using a single upper-layer
session. session.
The FEC Instance ID is an integer value that identifies a specific The FEC Instance ID is an integer value that identifies a specific
instance of an Under-Specified FEC scheme. This value is not used instance of an Under-Specified FEC scheme. This value is not used
for Fully-Specified FEC schemes. The FEC Instance ID is scoped by for Fully-Specified FEC schemes. The FEC Instance ID is scoped by
the FEC Encoding ID, and FEC Instance ID values are subject to IANA the FEC Encoding ID, and FEC Instance ID values are subject to IANA
registration. registration.
The FEC Encoding ID and FEC Instance ID are essential for the decoder The FEC Encoding ID for Fully-Specified FEC Schemes and both the FEC
to decode an object and thus are part of the FEC Object Transmission Encoding ID and FEC Instance ID for Under-Specified FEc Schemes are
Information. essential for the decoder to decode an object and thus are part of
the FEC Object Transmission Information.
The following requirements apply to all FEC schemes, whether Fully- The following requirements apply to all FEC schemes, whether Fully-
Specified or Under-Specified: Specified or Under-Specified:
o The type, semantics and an encoding format for the FEC Payload ID o The type, semantics and an encoding format for the FEC Payload ID
and the FEC Object Transmission Information MUST be defined. and the FEC Object Transmission Information MUST be defined.
o A value for the FEC Encoding ID MUST be reserved and associated o A value for the FEC Encoding ID MUST be reserved and associated
with the types, semantics and encoding format of the FEC Payload with the types, semantics and encoding format of the FEC Payload
ID and the the FEC Object Transmission Information. ID and the the FEC Object Transmission Information.
The specification for an Under-Specified FEC Scheme MAY allocate a The specification for an Under-Specified FEC Scheme MAY allocate a
sub-field within the Scheme-specific FEC Object Transmission sub-field within the Scheme-specific FEC Object Transmission
Information element which is for instance-specific information. Each Information element which is for instance-specific information. Each
specific instance of the Under-Specified FEC Scheme may then use this specific instance of the Under-Specified FEC Scheme may then use this
field in an instance-specific way. The FEC scheme should define the field in an instance-specific way. The FEC scheme should define the
scheme-specific FEC Object Transmission Information element in such a scheme-specific FEC Object Transmission Information element in such a
way that receivers that do not support the received FEC Instance ID way that receivers that do not support the received FEC Instance ID
can still parse and interpret the scheme-speific FEC Object can still parse and interpret the scheme-specific FEC Object
Transmission Information element with the exception of the instance- Transmission Information element with the exception of the instance-
specific field. specific field.
An already defined Under-Specified FEC Scheme (i.e. FEC Encoding ID An already defined Under-Specified FEC Scheme (i.e. FEC Encoding ID
value) MUST be reused if the associated FEC Payload ID and FEC Object value) MUST be reused if the associated FEC Payload ID and FEC Object
Transmission Information have the required fields and encoding Transmission Information have the required fields and encoding
formats for a new Under-Specified FEC scheme instance. formats for a new Under-Specified FEC scheme instance.
An instance of an Under-Specified FEC scheme is fully identified by An instance of an Under-Specified FEC scheme is fully identified by
the tuple (FEC Encoding ID, FEC Instance ID). The tuple MUST the tuple (FEC Encoding ID, FEC Instance ID). The tuple MUST
skipping to change at page 13, line 19 skipping to change at page 12, line 19
provide information on how to obtain the the Under-Specified FEC provide information on how to obtain the the Under-Specified FEC
scheme instance identified by the tuple, e.g., a pointer to a scheme instance identified by the tuple, e.g., a pointer to a
publicly available reference-implementation or the name and contacts publicly available reference-implementation or the name and contacts
of a company that sells it, either separately or embedded in another of a company that sells it, either separately or embedded in another
product. product.
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 Encoding IDs for Fully-Specified FEC schemes and the range 128-255
for the values of Under-Specified FEC schemes. for the values of Under-Specified FEC schemes.
6.2 FEC Object Transmission Information 6.2. FEC Object Transmission Information
The FEC Object Transmission Information contains information which is The FEC Object Transmission Information contains information which is
essential to the decoder in order to decode the encoded object. It essential to the decoder in order to decode the encoded object. It
may also contain information which is required to decode certain may also contain information which is required to decode certain
groups of encoding symbols, for example individual Source Blocks groups of encoding symbols, for example individual Source Blocks
within the object. This information is communicated reliably by the within the object. This information is communicated reliably by the
CDP to the receiver(s) as described in Section 8. CDP to the receiver(s) as described in Section 8.
The FEC Object Transmission Information may consist of several The FEC Object Transmission Information may consist of several
elements and each element may be one of three types, as follows: elements and each element may be one of three types, as follows:
Mandatory: These elements are defined in this specification and are Mandatory: These elements are defined in this specification and are
mandatory for all FEC Schemes. Each FEC scheme specifies how the each mandatory for at least one of the two types of FEC Scheme.
values of the Mandatory FEC Object Transmission Information Each FEC scheme specifies how the values of the Mandatory FEC
elements are determined and each CDP specifies how this Object Transmission Information elements are determined and each
information is encoded and reliably communicated to the CDP specifies how this information is encoded and reliably
receiver(s). The Mandatory FEC Object Transmission Information communicated to the receiver(s). The Mandatory FEC Object
includes the identification of the FEC Scheme, which is needed by Transmission Information includes the identification of the FEC
the receiver to determine whether it supports the FEC Scheme. Scheme, which is needed by the receiver to determine whether it
supports the FEC Scheme.
Common: These elements are defined in this specification and are Common: These elements are defined in this specification and are
optional to be used by an FEC scheme. Each FEC scheme specifies optional to be used by an FEC scheme. Each FEC scheme specifies
which of the Common FEC Object Transmission Information elements which of the Common FEC Object Transmission Information elements
it uses and how the values of these elements are determined. Each it uses and how the values of these elements are determined. Each
FEC scheme also specifies an encoding format for the information. FEC scheme also specifies an encoding format for the information.
Each CDP must specify at least one of the following: Each CDP must specify at least one of the following:
1. A means to reliably communicated the Common FEC Object 1. A means to reliably communicated the Common FEC Object
Transmission Information elements to the receiver(s) using the Transmission Information elements to the receiver(s) using the
skipping to change at page 14, line 25 skipping to change at page 13, line 28
specify how the length of the Scheme-specific FEC Object specify how the length of the Scheme-specific FEC Object
Transmission Information can be determined by the receiver. Note Transmission Information can be determined by the receiver. Note
that although from the point of view of this specification and of that although from the point of view of this specification and of
CDPs there is only a single Scheme-specific FEC Object CDPs there is only a single Scheme-specific FEC Object
Transmission Information element, the FEC scheme may specify this Transmission Information element, the FEC scheme may specify this
element to contain multiple distinct pieces of information. element to contain multiple distinct pieces of information.
The Mandatory and Common FEC Object Transmission Information elements The Mandatory and Common FEC Object Transmission Information elements
are defined in the sections below. are defined in the sections below.
6.2.1 Transport of Object Transmission Information 6.2.1. Transport of FEC Object Transmission Information
It is the responsibility of the CDP to reliably transport the Object It is the responsibility of the CDP to reliably transport the FEC
Transmission Information to the receiver(s). Object Transmission Information to the receiver(s).
It is important to note that the encoding format of the Mandatory FEC It is important to note that the encoding format of the Mandatory FEC
Object Transmission Information elements (The FEC Encoding ID and FEC Object Transmission Information elements (The FEC Encoding ID and FEC
Instance ID) is defined by the CDP. This is so that the receiver can Instance ID) is defined by the CDP. This is so that the receiver can
identify the FEC Scheme to be used for interpreting the remaining FEC identify the FEC Scheme to be used for interpreting the remaining FEC
Object Transmission Information elements. All CDPs must define Object Transmission Information elements. All CDPs must define
encoding formats for all the Mandatory FEC Object Transmission encoding formats for all the Mandatory FEC Object Transmission
Information elements. Information elements.
Common FEC Object Transmission Information elements can be Common FEC Object Transmission Information elements can be
transported in two different ways: (a) the FEC Scheme defines an transported in two different ways: (a) the FEC Scheme defines an
encoding format for each Common Object Transmission Information encoding format for each Common FEC Object Transmission Information
element and the CDP transports it, or (b) the CDP defines an encoding element that it uses and the CDP transports it, or (b) the CDP
format and transports the information in this format. defines an encoding format and transports the information in this
format.
An FEC Scheme MUST define encoding formats for the Common FEC Object An FEC Scheme MUST define encoding formats for the Common FEC Object
Transmission Information elements. A CDP MAY define encoding formats Transmission Information elements that it uses. A CDP MAY define
for the Common FEC Object Transmission Information elements. The CDP encoding formats for the Common FEC Object Transmission Information
determines which way the Common FEC Object Transmission Information elements. The CDP determines which way the Common FEC Object
elements shall be transported, (a) or (b). Note that a CDP may Transmission Information elements shall be transported, (a) or (b).
provide support for one or both options.
Note that a CDP may provide support for one or both options.
In the case that the CDP uses the encoding formats specified by the In the case that the CDP uses the encoding formats specified by the
FEC scheme then it may simply concatenate the encoding formats FEC scheme then it may simply concatenate the encoding formats
defined by the FEC scheme or it may carry each element in a seperate defined by the FEC scheme or it may carry each element in a seperate
field or wrapper within the CDP. The FEC scheme must define the field or wrapper within the CDP. The FEC scheme must define the
encoding formats of the Common FEC Object Transmission Information encoding formats of the Common FEC Object Transmission Information
elements in such a way that the length of each element is either elements that it uses in such a way that the length of each element
fixed or can be determined from the encoded data itself. is either fixed or can be determined from the encoded data itself.
The encoding format of the Scheme-specific FEC Object Transmission The encoding format of the Scheme-specific FEC Object Transmission
Information element is defined by the FEC scheme. CDPs specify only Information element is defined by the FEC scheme. CDPs specify only
how the resulting byte sequence is communicated. As with encoding how the resulting byte sequence is communicated. As with encoding
formats for the Common FEC Oject Transmission Information elements formats for the Common FEC Oject Transmission Information elements
the length of the Scheme-specific FEC Object Transmission Information the length of the Scheme-specific FEC Object Transmission Information
must either be fixed or it must be possible to determine the length must either be fixed or it must be possible to determine the length
from the encoded data itself. from the encoded data itself.
6.2.2 Opacity of Object Transmission Information 6.2.2. Opacity of FEC Object Transmission Information
The Scheme-specific FEC Object Transmission Information element is The Scheme-specific FEC Object Transmission Information element is
opaque to the CDP in the sense that inspecting the contents of this opaque to the CDP in the sense that inspecting the contents of this
element can only be done if FEC scheme-specific logic is included in element can only be done if FEC scheme-specific logic is included in
the CDP. the CDP.
The encoding formats defined by the FEC scheme for the Common FEC The encoding formats defined by the FEC scheme for the Common FEC
Object Transmission Information elements are also opaque to the CDP Object Transmission Information elements are also opaque to the CDP
in the same sense. in the same sense.
The encoding formats defined by the CDP for the Common FEC Object The encoding formats defined by the CDP for the Common FEC Object
Transmission Information elements are not opaque in this sense, Transmission Information elements are not opaque in this sense,
although it must be considered that different FEC Schemes may use although it must be considered that different FEC Schemes may use
different combinations of the Common FEC Object Transmission different combinations of the Common FEC Object Transmission
Information elements. Information elements.
6.2.3 Mandatory FEC Object Transmission Information elements 6.2.3. Mandatory FEC Object Transmission Information elements
The Mandatory FEC Object Transmission Information elements are: The Mandatory FEC Object Transmission Information elements are:
FEC Encoding ID: an integer between 0 and 255 inclusive identifying a FEC Encoding ID: an integer between 0 and 255 inclusive identifying a
specific FEC scheme (Fully-Specified or Under-Specified.) specific FEC scheme (Fully-Specified or Under-Specified.)
FEC Instance ID (if the FEC Encoding ID identifies an Under-Specified FEC Instance ID (if the FEC Encoding ID identifies an Under-Specified
FEC scheme): an integer between 0 and 65535 inclusive identifying an FEC scheme): an integer between 0 and 65535 inclusive identifying an
instance of an Under-specifed FEC scheme instance of an Under-specifed FEC scheme
6.2.4 Common FEC Object Transmission Information elements 6.2.4. Common FEC Object Transmission Information elements
The Common FEC Object Transmission Information elements are described The Common FEC Object Transmission Information elements are described
below. Note that this specification does not provide complete below. Note that this specification does not provide complete
definitions of these fields. Instead only aspects of the abstract definitions of these fields. Instead only aspects of the abstract
type are defined. The precise type and semantics are defined for type are defined. The precise type and semantics are defined for
each FEC scheme in the FEC scheme specification. each FEC scheme in the FEC scheme specification.
Transfer-Length: a non-negative integer indicating the length of the Transfer-Length: a non-negative integer indicating the length of the
object in bytes object in bytes
Encoding-Symbol-Length: a non-negative integer indicating the length Encoding-Symbol-Length: a non-negative integer indicating the length
of each encoding symbol in bytes of each encoding symbol in bytes
Maximum-Source-Block-Length: a non-negative integer indicating the Maximum-Source-Block-Length: a non-negative integer indicating the
maximum number of source symbols in a source block maximum number of source symbols in a source block
Max-Number-of-Encoding-Symbols: a non-negative integer indicating the Max-Number-of-Encoding-Symbols: a non-negative integer indicating the
maximum number of encoding symbols (i.e. source plus repair maximum number of encoding symbols (i.e. source plus repair
symbols in the case of a systematic code) symbols in the case of a systematic code)
FEC Schemes define the precise type of these elements and in FEC Schemes define the precise type of those of the above elements
particular may restrict the value range of each element. FEC Schemes that they use and in particular may restrict the value range of each
also define an encoding format for each of the above elements that element. FEC Schemes also define an encoding format for each of the
they require. CDPs may also provide an encoding format for each above elements that they use. CDPs may also provide an encoding
element in which case this encoding format MUST be capable of format for each element in which case this encoding format MUST be
representing values up to (2^^48)-1 in the case of the Transfer- capable of representing values up to (2^^48)-1 in the case of the
Length and up to (2^^32)-1 for the other elements. CDPs may Transfer-Length and up to (2^^32)-1 for the other elements. CDPs may
additionally or alternatively provide a mechanism to transport these additionally or alternatively provide a mechanism to transport these
elements encoded according to the encoding format defined by the FEC elements encoded according to the encoding format defined by the FEC
scheme. For example, FLUTE [9] specifies an XML-based encoding scheme. For example, FLUTE [8] specifies an XML-based encoding
format for these elements, but can also transport FEC scheme-specific format for these elements, but can also transport FEC scheme-specific
encoding formats within the EXT-FTI header extension. encoding formats within the EXT-FTI header extension.
6.2.5 Scheme-specific FEC Object Transmission Information element 6.2.5. Scheme-specific FEC Object Transmission Information element
The Scheme-specific FEC Object Transmission Information element may The Scheme-specific FEC Object Transmission Information element may
be used by an FEC Scheme to communicate information which is be used by an FEC Scheme to communicate information which is
essential to the decoder which cannot adequately be represented essential to the decoder which cannot adequately be represented
within the Mandatory or Common FEC Object Transmission Information within the Mandatory or Common FEC Object Transmission Information
elements. elements.
From the point of view of a CDP, the Scheme-specific FEC Object From the point of view of a CDP, the Scheme-specific FEC Object
Transmission Information element is an opaque, variable length, Transmission Information element is an opaque, variable length,
bitstring. The FEC Scheme defines the structure of this bitstring, bitstring. The FEC Scheme defines the structure of this bitstring,
which may contain multiple distinct elements. which may contain multiple distinct elements.
6.3 FEC Payload ID 6.3. FEC Payload ID
The FEC Payload ID contains information which indicates to the FEC The FEC Payload ID contains information which indicates to the FEC
decoder the relationships between the encoding symbols carried by a decoder the relationships between the encoding symbols carried by a
particular packet and the FEC encoding transformation. For example particular packet and the FEC encoding transformation. For example
if the packet carries source symbols then the FEC Payload ID if the packet carries source symbols then the FEC Payload ID
indicates which source symbols of the object are carried by the indicates which source symbols of the object are carried by the
packet. If the packet carries repair symbols, then the FEC Payload packet. If the packet carries repair symbols, then the FEC Payload
ID indicates how those repair symbols were constructed from the ID indicates how those repair symbols were constructed from the
object. object.
skipping to change at page 18, line 30 skipping to change at page 17, line 30
symbol. symbol.
3. The type and semantics of the FEC Object Transmission 3. The type and semantics of the FEC Object Transmission
Information. The FEC Scheme MAY define additional restrictions Information. The FEC Scheme MAY define additional restrictions
on the type (including value range) of the Common FEC Object on the type (including value range) of the Common FEC Object
Transmission Information elements. Transmission Information elements.
4. An encoding format for the Common FEC Object Transmission 4. An encoding format for the Common FEC Object Transmission
Information elements used by the FEC Scheme. Information elements used by the FEC Scheme.
Fully-specified FEC schemes MUST further specify: Fully-Specified FEC schemes MUST further specify:
1. A full specification of the FEC code. 1. A full specification of the FEC code.
This specification MUST precisely define the valid FEC Object This specification MUST precisely define the valid FEC Object
Transmission Information values, the valid FEC Payload ID values Transmission Information values, the valid FEC Payload ID values
and the valid packet payload sizes for any given object (where and the valid packet payload sizes for any given object (where
packet payload refers to the space - not necessarily contiguous - packet payload refers to the space - not necessarily contiguous -
within a packet dedicated to carrying encoding symbol bytes). within a packet dedicated to carrying encoding symbol bytes).
Furthermore, given an object, a valid Object Transmission
Information value, a valid FEC Payload ID value and a valid Furthermore, given an object, valid values for each of the FEC
packet payload size, the specification MUST uniquely define the Object Transmission Information elements used by the FEC Scheme,
values of the encoding symbol bytes to be included in the packet a valid FEC Payload ID value and a valid packet payload size, the
specification MUST uniquely define the values of the encoding
symbol bytes to be included in the packet payload of a packet
with the given FEC Payload ID value. with the given FEC Payload ID value.
A common and simple way to specify the FEC code to the required A common and simple way to specify the FEC code to the required
level of detail is to provide a precise specification of an level of detail is to provide a precise specification of an
encoding algorithm which, given an object, a valid FEC Object encoding algorithm which, given an object, valid values for each
Transmission Information for the object, a valid FEC Payload ID of the FEC Object Transmission Information elements used by the
and packet payload length as input produces the exact value of FEC Scheme for the object, a valid FEC Payload ID and packet
the encoding symbol bytes as output. payload length as input produces the exact value of the encoding
symbol bytes as output.
2. A description of practical encoding and decoding algorithms. 2. A description of practical encoding and decoding algorithms.
This description need not be to the same level of detail as for This description need not be to the same level of detail as for
(1) above, however it must be sufficient to demonstrate that (1) above, however it must be sufficient to demonstrate that
encoding and decoding of the code is both possible and practical. encoding and decoding of the code is both possible and practical.
FEC scheme specifications MAY additionally define the following: FEC scheme specifications MAY additionally define the following:
1. Type, semantics and encoding format of a Scheme-specific FEC 1. Type, semantics and encoding format of a Scheme-specific FEC
skipping to change at page 21, line 17 skipping to change at page 20, line 17
A specification for a CDP that uses this building block MUST include A specification for a CDP that uses this building block MUST include
the following things: the following things:
1. Definitions of encoding formats for the Mandatory FEC Object 1. Definitions of encoding formats for the Mandatory FEC Object
Transmission Information elements. Transmission Information elements.
2. A means to reliably communicate the Mandatory FEC Object 2. A means to reliably communicate the Mandatory FEC Object
Transmission Information elements from sender to receiver(s) Transmission Information elements from sender to receiver(s)
using the encoding format defined in (1). using the encoding format defined in (1).
3. A means to reliably communicate the Scheme-specific FEC Object 3. Means to reliably communicate the Common FEC Object Transmission
Transmission Information element from sender to receiver(s) using
the encoding format of the Scheme-specific FEC Object
Transmission Information element defined by the FEC scheme.
4. Means to reliably communicate the Common FEC Object Transmission
Information element from sender to receiver(s) using either or Information element from sender to receiver(s) using either or
both of (a) encoding formats defined by the FEC Scheme or (b) both of (a) encoding formats defined by the FEC Scheme or (b)
encoding formats defined by the CDP encoding formats defined by the CDP
4. A means to reliably communicate the Scheme-specific FEC Object
Transmission Information element from sender to receiver(s) using
the encoding format of the Scheme-specific FEC Object
Transmission Information element defined by the FEC scheme.
5. A means to communicate the FEC Payload ID in association with a 5. A means to communicate the FEC Payload ID in association with a
data packet. Note that the encoding format of the FEC Payload ID data packet. Note that the encoding format of the FEC Payload ID
is defined by the FEC Scheme. is defined by the FEC Scheme.
If option (b) of (4) above is used, then the CDP MUST specify an If option (b) of (3) above is used, then the CDP MUST specify an
encoding format for the Common FEC Object Transmission Information encoding format for the Common FEC Object Transmission Information
elements. elements.
CDPs MAY additionally specify the following things: CDPs MAY additionally specify the following things:
1. A means to indicate whether the FEC Payload ID within a packet is 1. A means to indicate whether the FEC Payload ID within a packet is
encoded according to the format for packets including only source encoded according to the format for packets including only source
symbols or according to the format for packets including at least symbols or according to the format for packets including at least
one repair symbol. one repair symbol.
9. Common algorithms 9. Common algorithms
This section describes certain algorithms which are expected to be This section describes certain algorithms which are expected to be
commonly required by FEC schemes or by CDPs. FEC Schemes and CDPs commonly required by FEC schemes or by CDPs. FEC Schemes and CDPs
SHOULD use these algorithms in preference to scheme or protocol SHOULD use these algorithms in preference to scheme or protocol
specific algorithms where appropriate. specific algorithms where appropriate.
9.1 Block partitioning algorithm 9.1. Block partitioning algorithm
This algorithm computes a partitioning of a object into source blocks This algorithm computes a partitioning of a object into source blocks
so that all source blocks are as close to being equal length as so that all source blocks are as close to being equal length as
possible. A first number of source blocks are of the same larger possible. A first number of source blocks are of the same larger
length, and the remaining second number of source blocks of the same length, and the remaining second number of source blocks of the same
smaller length. smaller length.
This algorithm is described in two steps, the second of which may be This algorithm is described in two steps, the second of which may be
useful in itself as an independent algorithm in some cases. In the useful in itself as an independent algorithm in some cases. In the
first step, the number of source symbols (T) and the number of source first step, the number of source symbols (T) and the number of source
skipping to change at page 22, line 34 skipping to change at page 21, line 34
Source Block Length (B) and Symbol Length (E). Source Block Length (B) and Symbol Length (E).
In the second step, the partitioning of the object is derived from In the second step, the partitioning of the object is derived from
the number of source symbols (T) and the number of source blocks (N). the number of source symbols (T) and the number of source blocks (N).
The partitioning is defined in terms of a first number of source The partitioning is defined in terms of a first number of source
blocks (I), a second number of source blocks (N-I), the length of blocks (I), a second number of source blocks (N-I), the length of
each of the first source blocks (A_large) and the length of each of each of the first source blocks (A_large) and the length of each of
the second source blocks (A_small). the second source blocks (A_small).
This algorithm is identical to the one specified in Section 5.1.2.3 This algorithm is identical to the one specified in Section 5.1.2.3
of FLUTE [9] of FLUTE [8]
The following notation is used in the description below: The following notation is used in the description below:
ceil[x] denotes x rounded up to the nearest integer. ceil[x] denotes x rounded up to the nearest integer.
floor[x] denotes x rounded down to the nearest integer. floor[x] denotes x rounded down to the nearest integer.
9.1.1 First Step 9.1.1. First Step
Input: Input:
B -- Maximum Source Block Length, i.e., the maximum number of source B -- Maximum Source Block Length, i.e., the maximum number of source
symbols per source block symbols per source block
L -- Transfer Length in bytes
L -- Transfer Length in bytes
E -- Encoding Symbol Length in bytes E -- Encoding Symbol Length in bytes
Output: Output:
T -- the number of source symbols in the object. T -- the number of source symbols in the object.
N -- The number of source blocks into which the object shall be N -- The number of source blocks into which the object shall be
partitioned. partitioned.
Algorithm: Algorithm:
1. The number of source symbols in the transport object is computed 1. The number of source symbols in the transport object is computed
as T = ceil[L/E]. as T = ceil[L/E].
2. The transport object shall be partitioned into N = ceil[T/B] 2. The transport object shall be partitioned into N = ceil[T/B]
source blocks. source blocks.
9.1.2 Second step 9.1.2. Second step
Input: Input:
T -- the number of source symbols in the object. T -- the number of source symbols in the object.
N -- The number of source blocks into which the object is N -- The number of source blocks into which the object is
partitioned. partitioned.
Output: Output:
skipping to change at page 25, line 8 skipping to change at page 24, line 8
Each of the first I source blocks then consists of A_large source Each of the first I source blocks then consists of A_large source
symbols, each source symbol is E bytes in length. Each of the symbols, each source symbol is E bytes in length. Each of the
remaining N-I source blocks consist of A_small source symbols, each remaining N-I source blocks consist of A_small source symbols, each
source symbol is E bytes in length except that the last source symbol source symbol is E bytes in length except that the last source symbol
of the last source block is L-(((L-1)/E) rounded down to the nearest of the last source block is L-(((L-1)/E) rounded down to the nearest
integer)*E bytes in length. integer)*E bytes in length.
10. Requirements from other building blocks 10. 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 CDP MUST provide congestion control that
conforms to [5], and thus this MUST be provided by another building conforms to [6], and thus this MUST be provided by another building
block when the FEC building block is used in a protocol. block when the FEC building block is used in a CDP.
There are no other specific requirements from other building blocks There are no other specific requirements from other building blocks
for the use of this FEC building block. However, any protocol that for the use of this FEC building block. However, any CDP that uses
uses the FEC building block will inevitably use other building blocks the FEC building block may use other building blocks for example to
for example to provide support for sending higher level session provide support for sending higher level session information within
information within data packets containing FEC encoding symbols. data packets containing FEC encoding symbols.
11. Security Considerations 11. Security Considerations
Data delivery can be subject to denial-of-service attacks by Data delivery can be subject to denial-of-service attacks by
attackers which send corrupted packets that are accepted as attackers which send corrupted packets that are accepted as
legitimate by receivers. This is particularly a concern for legitimate by receivers. This is particularly a concern for
multicast delivery because a corrupted packet may be injected into multicast delivery because a corrupted packet may be injected into
the session close to the root of the multicast tree, in which case the session close to the root of the multicast tree, in which case
the corrupted packet will arrive to many receivers. This is the corrupted packet will arrive to many receivers. This is
particularly a concern for the FEC building block because the use of particularly a concern for the FEC building block because the use of
even one corrupted packet containing encoding data may result in the even one corrupted packet containing encoding data may result in the
decoding of an object that is completely corrupted and unusable. It decoding of an object that is completely corrupted and unusable. It
is thus RECOMMENDED that the decoded objects be checked for integrity is thus RECOMMENDED that the decoded objects be checked for integrity
before delivering objects to an application. For example, an MD5 before delivering objects to an application. For example, an MD5
hash [6] of an object may be appended before transmission, and the hash [7] of an object may be appended before transmission, and the
MD5 hash is computed and checked after the object is decoded but MD5 hash is computed and checked after the object is decoded but
before it is delivered to an application. Moreover, in order to before it is delivered to an application. Moreover, in order to
obtain strong cryptographic integrity protection a digital signature obtain strong cryptographic integrity protection a digital signature
verifiable by the receiver SHOULD be computed on top of such a hash verifiable by the receiver SHOULD be computed on top of such a hash
value. It is also RECOMMENDED that a packet authentication protocol value. It is also RECOMMENDED that a packet authentication protocol
such as TESLA [10] be used to detect and discard corrupted packets such as TESLA [9] be used to detect and discard corrupted packets
upon arrival. Furthermore, it is RECOMMENDED that Reverse Path upon arrival. Furthermore, it is RECOMMENDED that Reverse Path
Forwarding checks be enabled in all network routers and switches Forwarding checks be enabled in all network routers and switches
along the path from the sender to receivers to limit the possibility along the path from the sender to receivers to limit the possibility
of a bad agent successfully injecting a corrupted packet into the of a bad agent successfully injecting a corrupted packet into the
multicast tree data path. multicast tree data path.
Another security concern is that some FEC information may be obtained Another security concern is that some FEC information may be obtained
by 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 description is forged or corrupted then the receivers will not use
the correct protocol for decoding content from received packets. To the correct protocol for decoding content from received packets. To
skipping to change at page 27, line 19 skipping to change at page 26, line 19
hierarchical: FEC Encoding IDs scope independent ranges of FEC hierarchical: FEC Encoding IDs scope independent ranges of FEC
Instance IDs. Only FEC Encoding IDs that correspond to Under- Instance IDs. Only FEC Encoding IDs that correspond to Under-
Specified FEC schemes scope a corresponding set of FEC Instance IDs. Specified FEC schemes scope a corresponding set of FEC Instance IDs.
The FEC Encoding ID and FEC Instance IDs are non-negative integers. The FEC Encoding ID and FEC Instance IDs are non-negative integers.
In this document, the range of values for FEC Encoding IDs is 0 to 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 255. Values from 0 to 127 are reserved for Fully-Specified FEC
schemes and Values from 128 to 255 are reserved for Under-Specified schemes and Values from 128 to 255 are reserved for Under-Specified
FEC schemes, as described in more detail in Section 6.1. FEC schemes, as described in more detail in Section 6.1.
12.1 Explicit IANA Assignment Guidelines 12.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
The values that can be assigned within the "ietf:rmt:fec:encoding" The values that can be assigned within the "ietf:rmt:fec:encoding"
name-space are numeric indexes in the range [0, 255], boundaries name-space are numeric indexes in the range [0, 255], boundaries
included. Assignment requests are granted on a "IETF Consensus" included. Assignment requests are granted on a "IETF Consensus"
basis as defined in [8]. basis as defined in [2].
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 associated with the "ietf:rmt:fec:encoding" name-space. Each value
of "ietf:rmt:fec:encoding" assigned in the range [128, 255] has a of "ietf:rmt:fec:encoding" assigned in the range [128, 255] has a
separate "ietf:rmt:fec:encoding:instance" sub-name-space that it separate "ietf:rmt:fec:encoding:instance" sub-name-space that it
scopes. Values of "ietf:rmt:fec:encoding" in the range [0, 127] do scopes. Values of "ietf:rmt:fec:encoding" in the range [0, 127] do
not scope a "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 "ietf:rmt:fec:encoding: The values that can be assigned within each "ietf:rmt:fec:encoding:
instance" sub-name-space are non-negative integers less than 65536. instance" sub-name-space are non-negative integers less than 65536.
Assignment requests are granted on a "First Come First Served" basis Assignment requests are granted on a "First Come First Served" basis
as defined in [8]. The same value of "ietf:rmt:fec:encoding: as defined in [2]. The same value of "ietf:rmt:fec:encoding:
instance" can be assigned within multiple distinct sub-name-spaces, instance" can be assigned within multiple distinct sub-name-spaces,
i.e., the same value of "ietf:rmt:fec:encoding:instance" can be used i.e., the same value of "ietf:rmt:fec:encoding:instance" can be used
for multiple values of "ietf:rmt:fec:encoding". for multiple values of "ietf:rmt:fec:encoding".
Requestors of "ietf:rmt:fec:encoding:instance" assignments MUST Requestors of "ietf:rmt:fec:encoding:instance" assignments MUST
provide the following information: provide the following information:
o The value of "ietf:rmt:fec:encoding" that scopes the "ietf:rmt: 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 fec:encoding:instance" sub-name-space. This must be in the range
[128, 255]. [128, 255].
skipping to change at page 29, line 7 skipping to change at page 28, line 7
rmt:fec:encoding:instance" assigned, and a way to obtain it (e.g., rmt:fec:encoding:instance" assigned, and a way to obtain it (e.g.,
a pointer to a publicly available reference-implementation or the a pointer to a publicly available reference-implementation or the
name and contacts of a company that sells it, either separately or name and contacts of a company that sells it, either separately or
embedded in a product). 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.
13. Acknowledgments 13. Acknowledgments
This document is largely based on RFC3452 [2] and thus thanks are due This document is largely based on RFC3452 [3] and thus thanks are due
to the additional authors of that document: J. Gemmell, L. Rizzo, M. to the additional authors of that document: J. Gemmell, L. Rizzo, M.
Handley, J. Crowcroft. Handley, J. Crowcroft.
14. References 14. References
14.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
14.2. Informative References
[3] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M.,
and J. Crowcroft, "Forward Error Correction (FEC) Building and J. Crowcroft, "Forward Error Correction (FEC) Building
Block", RFC 3452, December 2002. Block", RFC 3452, December 2002.
[3] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., [4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M.,
and J. Crowcroft, "The Use of Forward Error Correction (FEC) in and J. Crowcroft, "The Use of Forward Error Correction (FEC) in
Reliable Multicast", RFC 3453, December 2002. Reliable Multicast", RFC 3453, December 2002.
[4] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable [5] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable
Multicast Transport (RMT) Building Blocks and Protocol Multicast Transport (RMT) Building Blocks and Protocol
Instantiation documents", RFC 3269, April 2002. Instantiation documents", RFC 3269, April 2002.
[5] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF [6] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998. Application Protocols", RFC 2357, June 1998.
[6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [7] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[7] Masinter, L., "Hyper Text Coffee Pot Control Protocol [8] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
(HTCPCP/1.0)", RFC 2324, April 1998.
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[9] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
"FLUTE - File Delivery over Unidirectional Transport", "FLUTE - File Delivery over Unidirectional Transport",
RFC 3926, October 2004. RFC 3926, October 2004.
[10] Perrig, A., Cametti, R., Song, D., and J. Tygar, "Efficient and [9] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe,
Secure Source Authentication for Multicast", February 2001. "Timed Efficient Stream Loss-Tolerant Authentication (TESLA):
Multicast Source Authentication Transform Introduction",
Network and Distributed System Security Symposium RFC 4082, June 2005.
NDDS 2001
pp. 35-46
[11] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., [10] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S.,
and M. Luby, "Reliable Multicast Transport Building Blocks for and M. Luby, "Reliable Multicast Transport Building Blocks for
One-to-Many Bulk-Data Transfer", RFC 3048, January 2001. One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
Authors' Addresses Authors' Addresses
Mark Watson Mark Watson
Digital Fountain Digital Fountain
39141 Civic Center Drive 39141 Civic Center Drive
Suite 300 Suite 300
Fremont, CA 94538 Fremont, CA 94538
 End of changes. 

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