draft-ietf-rmt-fec-bb-revised-07.txt   rfc5052.txt 
Reliable Multicast M. Watson Network Working Group M. Watson
Internet-Draft M. Luby Request for Comments: 5052 M. Luby
Obsoletes: 3452 (if approved) L. Vicisano Obsoletes: 3452 L. Vicisano
Intended status: Standards Track Digital Fountain Category: Standards Track Digital Fountain
Expires: October 20, 2007 April 18, 2007 August 2007
Forward Error Correction (FEC) Building Block Forward Error Correction (FEC) Building Block
draft-ietf-rmt-fec-bb-revised-07
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 20, 2007. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 bulk data codes to efficiently provide and/or augment reliability for bulk data
transfer over IP multicast. This document defines a framework for transfer over IP multicast. This document defines a framework for
the definition of the information that needs to be communicated in the definition of the information that needs to be communicated in
order to use an FEC code for bulk data transfer, in addition to the order to use an FEC code for bulk data transfer, in addition to the
encoded data itself, and for definition of formats and codes for encoded data itself, and for definition of formats and codes for
communcation of that information. Both information communicated with communication of that information. Both information communicated
the encoded data itself and information that needs to be communicated with the encoded data itself and information that needs to be
'out-of-band' are considered. The procedures for specifying new FEC communicated 'out-of-band' are considered. The procedures for
codes, defining the information communication requirements associated specifying new FEC codes, defining the information communication
with those codes and registering them with the Internet Assigned requirements associated with those codes and registering them with
Numbers Authority (IANA) are also described. The requirements on the Internet Assigned Numbers Authority (IANA) are also described.
Content Delivery Protocols which wish to use FEC codes defined within The requirements on Content Delivery Protocols that wish to use FEC
this framework are also defined. The companion document titled, "The codes defined within this framework are also defined. The companion
Use of Forward Error Correction (FEC) in Reliable Multicast" document titled "The Use of Forward Error Correction (FEC) in
describes some applications of FEC codes for delivering content. Reliable Multicast" describes some applications of FEC codes for
This document obsoletes RFC3452. delivering content. This document obsoletes RFC 3452.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 5 2. Definitions and Abbreviations ...................................4
3. Requirements notation . . . . . . . . . . . . . . . . . . . . 6 3. Requirements Notation ...........................................4
4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Rationale .......................................................5
5. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 5. Applicability Statement .........................................6
6. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Functionality ...................................................6
6.1. FEC Schemes . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. FEC Schemes ................................................8
6.2. FEC Object Transmission Information . . . . . . . . . . . 13 6.2. FEC Object Transmission Information .......................10
6.2.1. Transport of FEC Object Transmission Information . . . 14 6.2.1. Transport of FEC Object Transmission Information ...11
6.2.2. Opacity of FEC Object Transmission Information . . . . 15 6.2.2. Opacity of FEC Object Transmission Information .....12
6.2.3. Mandatory FEC Object Transmission Information 6.2.3. Mandatory FEC Object Transmission
elements . . . . . . . . . . . . . . . . . . . . . . . 15 Information Elements ...............................12
6.2.4. Common FEC Object Transmission Information elements . 16 6.2.4. Common FEC Object Transmission Information
6.2.5. Scheme-specific FEC Object Transmission Elements ...........................................12
Information element . . . . . . . . . . . . . . . . . 17 6.2.5. Scheme-Specific FEC Object Transmission
6.3. FEC Payload ID . . . . . . . . . . . . . . . . . . . . . . 17 Information Element ................................13
7. FEC scheme specifications . . . . . . . . . . . . . . . . . . 19 6.3. FEC Payload ID ............................................13
8. CDP specifications . . . . . . . . . . . . . . . . . . . . . . 22 7. FEC Scheme Specifications ......................................14
9. Common algorithms . . . . . . . . . . . . . . . . . . . . . . 23 8. CDP Specifications .............................................17
9.1. Block partitioning algorithm . . . . . . . . . . . . . . . 23 9. Common Algorithms ..............................................18
9.1.1. First Step . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Block Partitioning Algorithm ..............................18
9.1.2. Second step . . . . . . . . . . . . . . . . . . . . . 24 9.1.1. First Step .........................................18
10. Requirements from other building blocks . . . . . . . . . . . 25 9.1.2. Second step ........................................19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 10. Requirements from Other Building Blocks .......................20
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11. Security Considerations .......................................20
12.1. Explicit IANA Assignment Guidelines . . . . . . . . . . . 27 12. IANA Considerations ...........................................21
13. Changes from RFC3452 . . . . . . . . . . . . . . . . . . . . . 29 12.1. Explicit IANA Assignment Guidelines ......................21
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 13. Changes from RFC 3452 .........................................22
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 14. Acknowledgments ...............................................23
15.1. Normative References . . . . . . . . . . . . . . . . . . . 31 15. References ....................................................23
15.2. Informative References . . . . . . . . . . . . . . . . . . 31 15.1. Normative References .....................................23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 15.2. Informative References ...................................23
Intellectual Property and Copyright Statements . . . . . . . . . . 33
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 [10], specifically Section describes a building block as defined in [10], specifically Section
4.2 of that document and follows the general guidelines provided in 4.2 of that document, and follows the general guidelines provided in
[5]. [5].
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/schemes, without needing to know details of the specific codes/schemes, without needing to know details of the specific
FEC code/scheme that may be used FEC 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 and may support any kind of several distinct protocol mechanisms and may support any kind of
application requiring reliable transport - for example object application requiring reliable transport -- for example, object
delivery and streaming applications. delivery and streaming applications.
This document also provides detailed guidelines on how to write an This document also provides detailed guidelines on how to write an
RFC for an FEC scheme corresponding to a new FEC Encoding ID (for RFC for an FEC scheme corresponding to a new FEC Encoding ID (for
both Fully-Specified and Under-Specified FEC Schemes - see both Fully-Specified and Under-Specified FEC Schemes -- see Section
Section 4). 4).
RFC3452 [3], which is obsoleted by this document, contained a RFC3452 [3], which is obsoleted by this document, contained a
previous version, which was published in the "Experimental" category. previous version, which was published in the "Experimental" category.
RFC3452 was published as an Experimental RFC in part due to the lack RFC3452 was published as an Experimental RFC in part due to the lack
at that time of specified congestion control strategies suitable for at that time of specified congestion control strategies suitable for
use with Reliable Multicast protocols. use with Reliable Multicast protocols.
This Proposed Standard specification is thus based on RFC3452 [3] This Proposed Standard specification is thus based on RFC3452 [3]
updated according to accumulated experience and growing protocol updated according to accumulated experience and growing protocol
maturity since the publication of RFC3452 [3]. Said experience maturity since the publication of RFC3452 [3]. Said experience
applies both to this specification itself and to congestion control applies both to this specification itself and to congestion control
strategies related to the use of this specification. strategies related to the use of this specification.
The differences between RFC3452 [3] and this document listed in The differences between RFC 3452 [3] and this document are listed in
Section 13 Section 13.
2. Definitions/Abbreviations 2. Definitions and Abbreviations
Object: An ordered sequence of octets to be transferred by the Object: An ordered sequence of octets 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.
Source symbol: A symbol containing information from the original Source symbol: A symbol containing information from the original
object. object.
Repair symbol: A symbol containing information generated by the FEC Repair symbol: A symbol containing information generated by the FEC
code which can be used to recover lost source symbols. code which can be used to recover lost source symbols.
Encoding symbol: A source symbol or a repair symbol. Encoding symbol: A source symbol or a repair symbol.
Encoder: The FEC scheme specific functions required to transform a Encoder: The FEC scheme specific functions required to transform a
object into FEC encoded data. i.e. the functions that produce object into FEC encoded data. That is, the functions that produce
repair symbols using source symbols. repair symbols using source symbols.
Decoder: The FEC scheme specific functions required to transform Decoder: The FEC scheme-specific functions required to transform
received FEC encoded data into a copy of the original object received FEC-encoded data into a copy of the original object.
Receiver: A system supporting the receiving functions of a CDP and Receiver: A system supporting the receiving functions of a CDP and
FEC scheme according to this specification FEC scheme according to this specification.
Sender: A system supporting the sending functions of a CDP and FEC Sender: A system supporting the sending functions of a CDP and FEC
scheme according to this specification scheme according to this specification.
Source Block: A part of the object formed from a subset of the Source Block: A part of the object formed from a subset of the
object's source symbols object's source symbols.
CDP: Content Delivery Protocol CDP: Content Delivery Protocol
FEC: Forward Error Correction FEC: Forward Error Correction
3. Requirements notation 3. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
4. Rationale 4. Rationale
An FEC code, in the general sense, is a valuable basic component of An FEC code, in the general sense, is a valuable basic component of
any CDP that is to provide reliable delivery of an object. Using FEC any CDP that is to provide reliable delivery of an object. Using FEC
codes is effective in the context of IP multicast and reliable codes is effective in the context of IP multicast and reliable
skipping to change at page 7, line 21 skipping to change at page 5, line 21
for reconstructing an object even when the receivers have received for reconstructing an object even when the receivers have received
different encoding symbols. Furthermore, FEC codes can ameliorate or different encoding symbols. Furthermore, FEC codes can ameliorate or
even eliminate the need for feedback from receivers to senders to even eliminate the need for feedback from receivers to senders to
request retransmission of lost packets. request retransmission of lost packets.
Central to this document is the concept of an 'FEC Scheme', which we Central to this document is the concept of an 'FEC Scheme', which we
distinguish from the concept of an 'FEC code' or 'FEC algorithm'. An distinguish from the concept of an 'FEC code' or 'FEC algorithm'. An
FEC scheme defines the ancillary information and procedures which, FEC scheme defines the ancillary information and procedures which,
combined with an FEC code or algorithm specification, fully define combined with an FEC code or algorithm specification, fully define
how the FEC code can be used with CDPs. An FEC scheme may be how the FEC code can be used with CDPs. An FEC scheme may be
associated with a single standardised FEC code (A 'Fully-Specified' associated with a single standardized FEC code (A 'Fully-Specified'
FEC scheme) or may be applicable to many FEC codes (An 'Under- FEC scheme) or may be applicable to many FEC codes (An 'Under-
Specified' FEC scheme). 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 CDP which is compliant CDPs that make use of FEC schemes. Any CDP that is compliant to the
to the requirements specified in this document can make use of any requirements specified in this document can make use of any FEC
FEC scheme which is defined within the framework described here. scheme that is defined within the framework described here. Note
Note that FEC schemes may place restrictions on the types of CDP they that FEC schemes may place restrictions on the types of CDP they are
are intended to be used with. For example, some FEC schemes may be intended to be used with. For example, some FEC schemes may be
specific to particular types of application, such as file delivery or specific to particular types of application, such as file 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 CDPs or particular FEC schemes. The that is specific to particular CDPs or particular FEC schemes. The
primary functionality described in this document that is common to primary functionality described in this document that is common to
all such CDPs that use FEC codes is the definition and transport of all such CDPs that use FEC codes is the definition and transport of
three kinds of information from sender to receiver(s): encoding three kinds of information from sender to receiver(s):
symbols themselves, ancillary information associated with encoding
symbols (or groups of such symbols, such as the group of symbols in a
single packet, or the group of symbols related to a single source
block) and ancillary information associated with the whole object
being transferred. It is important to note that this an information
is only required by the receiver if one or more of the encoding
symbols to which it relates are received.
This document for example does not describe how receivers may request 1) encoding symbols themselves,
2) ancillary information associated with encoding symbols (or
groups of such symbols, such as the group of symbols in a
single packet, or the group of symbols related to a single
source block), and
3) ancillary information associated with the whole object being
transferred.
It is important to note that this information is only required by the
receiver if one or more of the encoding symbols to which it relates
are received.
This document 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 CDPs where requests for transmission are because although there are CDPs where requests for transmission are
of use, there are also CDPs that do not require such requests. of use, there are also CDPs that do not require such requests.
The companion document [4] 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 CDP MUST provide congestion control control. Any complete multicast CDP MUST provide congestion control
that conforms to [6], in particular Section 3.2 of that document. that conforms to [6], in particular, Section 3.2 of that document.
Thus, congestion control MUST be provided by another building block Thus, congestion control MUST be provided by another building block
when the FEC building block is used in a CDP. when the FEC building block is used in a CDP.
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 [4]. 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 to be sent either 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
of FEC information. Note that some CDPs may not use session-control kinds of FEC information. Note that some CDPs may not use session-
or feedback packets. control or feedback packets.
Data packets may sometimes serve as session-control packets as well; Data packets may sometimes serve as session-control packets as well;
both data and session-control packets generally travel downstream 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
neighboring router that provides recovery services. neighboring router that provides recovery services.
This document specifies both the FEC information that must be carried This document specifies both the FEC information that must be carried
in data packets and the FEC information that must be communicated in data packets and the FEC information that must be communicated
from sender to receiver(s) either out-of-band or in data packets. from sender to receiver(s) either out-of-band or in data packets.
Specification of protocol mechanisms for transporting this Specification of protocol mechanisms for transporting this
information, for example field and packet formats, is out of scope of information, for example, field and packet formats, is out of scope
this document. Instead, this document specifies at a higher level of this document. Instead, this document specifies at a higher level
the information that must be communicate and provides detailed the information that must be communicated and provides detailed
requirements for FEC Scheme and Content Delivery Protocol requirements for FEC Scheme and Content Delivery Protocol
specifications, which are where the detailed field and packet formats specifications, which are where the detailed field and packet formats
should be defined. should be defined.
FEC information is classified as follows: FEC information is classified as follows:
1. FEC information associated with an object 1. FEC information associated with an object
This is information that is essential for the FEC decoder to This is information that is essential for the FEC decoder to
decode a specific object. An example of this information is the decode a specific object. An example of this information is the
identity of the FEC scheme that is being used to encode the identity of the FEC scheme that is being used to encode the
object, in the form of the FEC Encoding ID. The FEC Encoding ID object, in the form of the FEC Encoding ID. The FEC Encoding ID
is described further below. This information may also include is described further below. This information may also include
FEC scheme-specific parameters for the FEC decoder. FEC scheme-specific parameters for the FEC decoder.
2. FEC information associated with specific encoding symbols for an 2. FEC information associated with specific encoding symbols for an
object object
This is information which is associated with one or more encoding
This is information that is associated with one or more encoding
symbols and is thus needed by the decoder whenever one or more of symbols and is thus needed by the decoder whenever one or more of
those encoding symbols have been received. Depending on the FEC those encoding symbols have been received. Depending on the FEC
scheme, information may be associated with individual symbols scheme, information may be associated with individual symbols
and/or with groups of symbols. One common such grouping is the and/or with groups of symbols. One common such grouping is the
group of symbols included within a single packet. Many FEC group of symbols included within a single packet. Many FEC
schemes also segment the object being encoded into multiple schemes also segment the object being encoded into multiple
'source blocks', each of which is processed independently for FEC 'source blocks', each of which is processed independently for FEC
purposes. Information about each source block is another type of purposes. Information about each source block is another type of
information associated with a group of encoding symbols, this information associated with a group of encoding symbols -- in
time the group of symbols which are related to a given source this case, the group of symbols which are related to a given
block. source block.
Two 'containers' are provided for communicating the FEC information Two 'containers' are provided for communicating the FEC information
described above, but there is not necessarily a one-to-one described above, but there is not necessarily a one-to-one
correspondence between the class of FEC information and the mechanism correspondence between the class of FEC information and the mechanism
used. The two mechanisms are: used. The two mechanisms are:
a. FEC Object Transmission Information a. FEC Object Transmission Information
CDPs must provide a reliable mechanism for communicating certain CDPs must provide a reliable mechanism for communicating certain
FEC information from sender to receiver(s). This information is FEC information from sender to receiver(s). This information is
skipping to change at page 11, line 37 skipping to change at page 8, line 14
depend on the particular FEC scheme. It includes all information depend on the particular FEC scheme. It includes all information
of the first class above and may include information of the of the first class above and may include information of the
second class. The FEC Object Transmission Information can be second class. The FEC Object Transmission Information can be
sent to a receiver within the data packet headers, within session sent to a receiver within the data packet headers, within session
control packets, or by some other means. control packets, or by some other means.
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
skipping to change at page 12, line 26 skipping to change at page 9, line 7
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 for Fully-Specified FEC Schemes and both the FEC The FEC Encoding ID for Fully-Specified FEC Schemes and both the FEC
Encoding ID and FEC Instance ID for Under-Specified FEC Schemes are Encoding ID and FEC Instance ID for Under-Specified FEC Schemes are
essential for the decoder to decode an object and thus are part of essential for the decoder to decode an object. Thus, they are part
the FEC Object Transmission Information. 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 FEC Object Transmission Information. ID and 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-specific 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
identify a single scheme instance that has at least one identify a single scheme instance that has at least one
implementation. The party that owns this tuple MUST be able to implementation. The party that owns this tuple MUST be able to
provide information on how to obtain the Under-Specified FEC scheme provide information on how to obtain the Under-Specified FEC scheme
instance identified by the tuple, e.g., a pointer to a publicly instance identified by the tuple, e.g., a pointer to a publicly
skipping to change at page 13, line 26 skipping to change at page 10, line 10
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
each mandatory for at least one of the two types of FEC Scheme. each mandatory for at least one of the two types of FEC Scheme.
Each FEC scheme specifies how the values of the Mandatory FEC Each FEC scheme specifies how the values of the Mandatory FEC
Object Transmission Information elements are determined and each Object Transmission Information elements are determined and each
skipping to change at page 13, line 50 skipping to change at page 10, line 34
Scheme, which is needed by the receiver to determine whether it Scheme, which is needed by the receiver to determine whether it
supports the FEC Scheme. 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. it uses and how the values of these elements are determined.
Scheme-specific: An FEC scheme may specify a single Scheme-specific Scheme-specific: An FEC scheme may specify a single Scheme-specific
FEC Object Transmission Information element. The FEC scheme FEC Object Transmission Information element. The FEC scheme
specifies the type, semantics and encoding format of the Scheme- specifies the type, semantics, and encoding format of the Scheme-
specific FEC Object Transmission Information element. The specific FEC Object Transmission Information element. The
resulting octet-string is known as the "encoded Scheme-specific resulting octet string is known as the "encoded Scheme-specific
FEC Object Transmission Information". Each CDP specifies how the FEC Object Transmission Information". Each CDP specifies how the
encoded Scheme-specific FEC Object Transmission is communicated encoded Scheme-specific FEC Object Transmission is communicated
reliably to the receiver(s) i.e. exactly where it shall be carried reliably to the receiver(s), i.e., exactly where it shall be
within packets of the CDP. Note that although from the point of carried within packets of the CDP. Note that although from the
view of this specification and of CDPs there is only a single point of view of this specification and of CDPs, there is only a
Scheme-specific FEC Object Transmission Information element, the single Scheme-specific FEC Object Transmission Information
FEC scheme may specify this element to contain multiple distinct element, the FEC scheme may specify this element to contain
pieces of information. multiple distinct pieces of information.
Each FEC scheme specifies an encoding format for the Common and Each FEC scheme specifies an encoding format for the Common and
Scheme-specific FEC Object Transmission Information. Each CDP must Scheme-specific FEC Object Transmission Information. Each CDP must
specify at least one of the following: specify at least one of the following:
1. A means to reliably communicate the Common FEC Object 1. A means to reliably communicate the Common FEC Object
Transmission Information elements to the receiver(s) using the Transmission Information elements to the receiver(s) using the
encoding format defined by the FEC scheme. encoding format defined by the FEC scheme.
2. An alternative, CDP specific, encoding format for each of the 2. An alternative, CDP-specific, encoding format for each of the
Common FEC Object Transmission Information elements. Common FEC Object Transmission Information elements.
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 FEC Object Transmission Information 6.2.1. Transport of FEC Object Transmission Information
It is the responsibility of the CDP to reliably transport the FEC It is the responsibility of the CDP to reliably transport the FEC
Object 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) is Object Transmission Information elements (the FEC Encoding ID) is
defined by the CDP. This is so that the receiver can identify the defined by the CDP. This is so that the receiver can identify the
FEC Scheme to be used for interpreting the remaining FEC Object FEC Scheme to be used for interpreting the remaining FEC Object
Transmission Information elements. All CDPs must define encoding Transmission Information elements. All CDPs must define encoding
formats for the Mandatory FEC Object Transmission Information formats for the Mandatory FEC Object Transmission Information
element. element.
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 the Common FEC Object Transmission Information encoding format for the Common FEC Object Transmission Information
elements that it uses and the CDP transports this encoded data block, elements that it uses, and the CDP transports this encoded data
or (b) the CDP defines an encoding format for each Common FEC Object block, or (b) the CDP defines an encoding format for each Common FEC
Transmission Information element and transports the information in Object Transmission Information element and transports the
this format. information in this format.
An FEC Scheme MUST define an encoding format for the Common FEC An FEC Scheme MUST define an encoding format for the Common FEC
Object Transmission Information elements that it uses. The resulting Object Transmission Information elements that it uses. The resulting
octet string is known as the "encoded Common FEC Object Transmission octet string is known as the "encoded Common FEC Object Transmission
Information". A CDP MAY define individual encoding formats for each Information". A CDP MAY define individual encoding formats for each
of the Common FEC Object Transmission Information elements. The of the Common FEC Object Transmission Information elements. The
choice of which way the Common FEC Object Transmission Information choice of which way the Common FEC Object Transmission Information
elements shall be transported, (a) or (b), is made by the Content elements shall be transported, (a) or (b), is made by the Content
Delivery Protocol and a particular method SHOULD be defined in the Delivery Protocol, and a particular method SHOULD be defined in the
Content Delivery Protocol specification. Note that a CDP may provide Content Delivery Protocol specification. Note that a CDP may provide
support for one or both options. support for one or both options.
In the case that the CDP uses the encoding format specified by the In the case that the CDP uses the encoding format specified by the
FEC scheme then it may simply concatenate the encoded Common FEC FEC scheme, it may simply concatenate the encoded Common FEC Object
Object Transmission Information and the encoded Scheme-specific FEC Transmission Information and the encoded Scheme-specific FEC Object
Object Transmission Information or it may carry each in a separate Transmission Information, or it may carry each in a separate field or
field or wrapper within the CDP. In the former case, the wrapper within the CDP. In the former case, the concatenated octet
concatenated octet-string is known as the encoded FEC Object string is known as the encoded FEC Object Transmission Information.
Transmission Information. The FEC scheme must define the encoding The FEC scheme must define the encoding format for the Common FEC
format for the Common FEC Object Transmission Information elements Object Transmission Information elements that it uses in such a way
that it uses in such a way that the length of each element is either that the length of each element is either fixed or can be determined
fixed or can be determined from the encoded data itself. 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 octet sequence is communicated. As with the how the resulting octet sequence is communicated. As with the
encoding format for the Common FEC Object Transmission Information encoding format for the Common FEC Object Transmission Information
elements the length of the Scheme-specific FEC Object Transmission elements, the length of the Scheme-specific FEC Object Transmission
Information must either be fixed or it must be possible to determine Information must either be fixed or be possible to determine from the
the length from the encoded data itself. encoded data itself.
6.2.2. Opacity of FEC 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.
Any encoding formats defined by the FEC scheme for the Common FEC Any 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.
Any encoding formats defined by the CDP for the Common FEC Object Any 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 element is: The Mandatory FEC Object Transmission Information element is:
FEC Encoding ID: an integer between 0 and 255 inclusive identifying FEC Encoding ID: an integer between 0 and 255 inclusive identifying
a specific FEC scheme (Fully-Specified or Under-Specified.) a specific FEC scheme (Fully-Specified or Under-Specified.)
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 with the exception of the FEC Instance ID, this below. Note that with the exception of the FEC Instance ID, this
specification does not provide complete definitions of these fields. specification does not provide complete definitions of these fields.
Instead only aspects of the abstract type are defined. The precise Instead, only aspects of the abstract type are defined. The precise
type and semantics are defined for each FEC scheme in the FEC scheme type and semantics are defined for each FEC scheme in the FEC scheme
specification. specification.
FEC Instance ID: an integer between 0 and 65535 inclusive FEC Instance ID: an integer between 0 and 65535 inclusive
identifying an instance of an Under-specifed FEC scheme identifying an instance of an Under-Specified FEC scheme
Transfer-Length: a non-negative integer indicating the length of the Transfer-Length: a non-negative integer indicating the length of the
object in octets object in octets
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 octets of each encoding symbol in octets
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 Max-Number-of-Encoding-Symbols: a non-negative integer indicating
the maximum number of encoding symbols (i.e. source plus repair the 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)
The FEC Instance ID MUST be used by all Under-specified FEC schemes The FEC Instance ID MUST be used by all Under-Specified FEC schemes
and MUST NOT be used by Fully-specified FEC Schemes. and MUST NOT be used by Fully-Specified FEC Schemes.
FEC Schemes define the precise type of those of the above elements FEC Schemes define the precise type of those of the above elements
that they use and in particular may restrict the value range of each that they use and in particular may restrict the value range of each
element. FEC Schemes also define an encoding format for the subset element. FEC Schemes also define an encoding format for the subset
of the above elements that they use. CDPs may also provide an of the above elements that they use. CDPs may also provide an
encoding format for each element in which case this encoding format encoding format for each element; in which case, this encoding format
MUST be capable of representing values up to (2^^16)-1 in the case of MUST be capable of representing values up to (2^^16)-1 in the case of
the FEC Instance ID, (2^^48)-1 in the case of the Transfer-Length and the FEC Instance ID, (2^^48)-1 in the case of the Transfer-Length,
up to (2^^32)-1 for the other elements. CDPs may additionally or and up to (2^^32)-1 for the other elements. CDPs may additionally or
alternatively provide a mechanism to transport the encoded Common FEC alternatively provide a mechanism to transport the encoded Common FEC
Object Transmission information defined by the FEC scheme. For Object Transmission information defined by the FEC scheme. For
example, FLUTE [8] specifies an XML-based encoding format for these example, FLUTE [8] specifies an XML-based encoding format for these
elements, but can also transport FEC scheme-specific encoding formats elements, but can also transport FEC scheme-specific encoding formats
within the EXT-FTI LCT header extension. within the EXT-FTI LCT 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 that is essential
essential to the decoder which cannot adequately be represented to the decoder and that cannot adequately be represented within the
within the Mandatory or Common FEC Object Transmission Information 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, octet Transmission Information element is an opaque, variable length, octet
string. The FEC Scheme defines the structure of this octet string, string. The FEC Scheme defines the structure of this octet string,
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 that 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.
The FEC Payload ID may also contain information about larger groups The FEC Payload ID may also contain information about larger groups
of encoding symbols of which those contained in the packet are part. of encoding symbols of which those contained in the packet are part.
For example, the FEC Payload ID may contain information about the For example, the FEC Payload ID may contain information about the
source block the symbols are related to. source block the symbols are related to.
The FEC Payload ID for a given packet is essential to the decoder if The FEC Payload ID for a given packet is essential to the decoder if
and only if the packet itself is received. Thus it must be possible and only if the packet itself is received. Thus, it must be possible
to obtain the FEC Payload ID from the received packet. Usually, the to obtain the FEC Payload ID from the received packet. Usually, the
FEC Payload ID is simply carried explicitly as a separate field FEC Payload ID is simply carried explicitly as a separate field
within each packet. In this case the size of the FEC Payload ID within each packet. In this case, the size of the FEC Payload ID
field SHOULD be a small fraction of the packet size. Some FEC field SHOULD be a small fraction of the packet size. Some FEC
schemes may specify means for deriving the relationship between the schemes may specify means for deriving the relationship between the
carried encoding symbols and the object implicitly from other carried encoding symbols and the object implicitly from other
information within the packet, such as protocol headers already information within the packet, such as protocol headers already
present. Such FEC schemes could obviously only be used with CDPs present. Such FEC schemes could obviously only be used with CDPs
which provided the appropriate information from which the FEC Payload which provided the appropriate information from which the FEC Payload
ID could be derived. ID could be derived.
The encoding format of the FEC Payload ID, including its size, is The encoding format of the FEC Payload ID, including its size, is
defined by the FEC Scheme. CDPs specify how the FEC Payload ID is defined by the FEC Scheme. CDPs specify how the FEC Payload ID is
carried within data packets i.e. the position of the FEC Payload ID carried within data packets, i.e., the position of the FEC Payload ID
within the CDP packet format and the how it is associated with within the CDP packet format and the how it is associated with
encoding symbols. encoding symbols.
FEC schemes for systematic FEC codes, that is, those codes in which FEC schemes for systematic FEC codes (that is, those codes in which
the original source data is included within the encoded data, MAY the original source data is included within the encoded data) MAY
specify two FEC Payload ID formats, one for packets carrying only specify two FEC Payload ID formats, one for packets carrying only
source symbols and another for packets carrying at least one repair source symbols and another for packets carrying at least one repair
symbol. CDPs must include an indication of which of the two FEC symbol. CDPs must include an indication of which of the two FEC
Payload ID formats is included in each packet if they wish to support Payload ID formats is included in each packet if they wish to support
such FEC Schemes. such FEC Schemes.
7. FEC scheme specifications 7. FEC Scheme Specifications
A specification for a new FEC scheme MUST include the following A specification for a new FEC scheme MUST include the following
things: things:
1. The FEC Encoding ID value that uniquely identifies the FEC 1. The FEC Encoding ID value that uniquely identifies the FEC
scheme. This value MUST be registered with IANA as described in scheme. This value MUST be registered with IANA as described in
Section 12. Section 12.
2. The type, semantics and encoding format of one or two FEC Payload 2. The type, semantics, and encoding format of one or two FEC
IDs. Where two FEC Payload ID formats are specified, then the Payload IDs. Where two FEC Payload ID formats are specified,
FEC scheme MUST be a systematic FEC code and one FEC Payload ID then the FEC scheme MUST be a systematic FEC code and one FEC
format MUST be designated for use with packets carrying only Payload ID format MUST be designated for use with packets
source symbols and the other FEC Payload ID format MUST be carrying only source symbols, and the other FEC Payload ID format
designated for use with packets carrying at least one repair MUST be designated for use with packets carrying at least one
symbol. repair 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 octets). -- within a packet dedicated to carrying encoding symbol octets).
Furthermore, given an object, valid values for each of the FEC Furthermore, given an object, valid values for each of the FEC
Object Transmission Information elements used by the FEC Scheme, Object Transmission Information elements used by the FEC Scheme,
a valid FEC Payload ID value and a valid packet payload size, the a valid FEC Payload ID value, and a valid packet payload size,
specification MUST uniquely define the values of the encoding the specification MUST uniquely define the values of the encoding
symbol octets to be included in the packet payload of a packet symbol octets 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, valid values for each encoding algorithm which, given an object, valid values for each
of the FEC Object Transmission Information elements used by the of the FEC Object Transmission Information elements used by the
FEC Scheme for the object, a valid FEC Payload ID and packet FEC Scheme for the object, a valid FEC Payload ID, and packet
payload length as input produces the exact value of the encoding payload length as input produces the exact value of the encoding
symbol octets as output. symbol octets 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
Object Transmission Information element. Object Transmission Information element.
Note that if an FEC scheme does not define a Scheme-specific FEC Note that if an FEC scheme does not define a Scheme-specific FEC
Object Transmission Information then such an element MUST NOT be Object Transmission Information element, then such an element MUST
introduced in future versions of the FEC Scheme. This requirement is NOT be introduced in future versions of the FEC Scheme. This
included to ensure backwards-compatibility of CDPs designed to requirement is included to ensure backwards-compatibility of CDPs
support only FEC Schemes which do not use the Scheme-specific FEC designed to support only FEC Schemes that do not use the Scheme-
Object Transmission Information element. specific FEC Object Transmission Information element.
Whenever an FEC scheme specification defines an 'encoding format' for Whenever an FEC scheme specification defines an 'encoding format' for
an element, this must be defined in terms of a sequence of octets an element, this must be defined in terms of a sequence of octets
which can be embedded within a protocol. The length of the encoding that can be embedded within a protocol. The length of the encoding
format MUST either be fixed or it must be possible to derive the format MUST either be fixed, or it must be possible to derive the
length from examining the encoded octets themselves. For example, length from examining the encoded octets themselves. For example,
the initial octets may include some kind of length indication. the initial octets may include some kind of length indication.
FEC schemes SHOULD make use of the Common FEC Object Transmission FEC schemes SHOULD make use of the Common FEC Object Transmission
Information elements in preference to including information in a Information elements in preference to including information in a
Scheme-specific FEC Object Transmission Information element. Scheme-specific FEC Object Transmission Information element.
FEC scheme specifications SHOULD use the terminology defined in this FEC scheme specifications SHOULD use the terminology defined in this
document and SHOULD follow the following format: document and SHOULD follow the following format:
skipping to change at page 21, line 4 skipping to change at page 16, line 35
1. Introduction <define whether the scheme is Fully-Specified or 1. Introduction <define whether the scheme is Fully-Specified or
Under-Specified> Under-Specified>
<describe the use-cases addressed by this FEC scheme> <describe the use-cases addressed by this FEC scheme>
2. Formats and Codes 2. Formats and Codes
2.1 FEC Payload ID(s) <define the type and format of one or two 2.1 FEC Payload ID(s) <define the type and format of one or two
FEC Payload IDs> FEC Payload IDs>
2.2 FEC Object Transmission Information 2.2 FEC Object Transmission Information
2.2.1 Mandatory <define the value of the FEC Encoding ID for 2.2.1 Mandatory <define the value of the FEC Encoding ID for
this FEC scheme> this FEC scheme>
2.2.2 Common <describe which Common FEC Object Transmission 2.2.2 Common <describe which Common FEC Object Transmission
Information elements are used by this FEC scheme, define Information elements are used by this FEC scheme, define
their value ranges and define an encoding format for them> their value ranges, and define an encoding format for
them>
2.2.3 Scheme-Specific <define the Scheme-specific FEC Object 2.2.3 Scheme-Specific <define the Scheme-specific FEC Object
Transmission Information, including an encoding format, if Transmission Information, including an encoding format, if
required> required>
3. Procedures <describe any procedures which are specific to this 3. Procedures <describe any procedures that are specific to this FEC
FEC scheme, in particular derivation and interpretation of the scheme, in particular derivation and interpretation of the fields
fields in the FEC Payload ID and FEC Object Transmission in the FEC Payload ID and FEC Object Transmission Information.>
Information.>
4. FEC code specification (for Fully-Specified FEC schemes only) 4. FEC code specification (for Fully-Specified FEC schemes only)
<provide a complete specification of the FEC Code> <provide a complete specification of the FEC Code>
Specifications MAY include additional sections, for example, Specifications MAY include additional sections such as those
examples. containing examples.
Each FEC scheme MUST be specified independently of all other FEC Each FEC scheme MUST be specified independently of all other FEC
schemes; for example, in a separate specification or a completely schemes; for example, in a separate specification or a completely
independent section of larger specification. independent section of a larger specification.
8. CDP specifications 8. CDP Specifications
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 an encoding formats for the Mandatory FEC Object 1. Definitions of an encoding format for the Mandatory FEC Object
Transmission Information element. Transmission Information element.
2. A means to reliably communicate the Mandatory FEC Object 2. A means to reliably communicate the Mandatory FEC Object
Transmission Information element from sender to receiver(s) using Transmission Information element from sender to receiver(s) using
the encoding format defined in (1). the encoding format defined in (1).
3. Means to reliably communicate the Common FEC Object Transmission 3. 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) the encoding format defined by the FEC Scheme or (b) both of (a) the encoding format defined by the FEC Scheme or (b)
encoding formats defined by the CDP encoding formats defined by the CDP
skipping to change at page 23, line 5 skipping to change at page 18, line 5
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 that 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 an object into source
so that all source blocks are as close to being equal length as blocks so that all source blocks are as close to being equal length
possible. A first number of source blocks are of the same larger as 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 are of the
smaller length. same 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
blocks (N) are derived from the Object transfer length (L), Maximum blocks (N) are derived from the Object transfer length (L), Maximum
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).
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
skipping to change at page 23, line 49 skipping to change at page 19, line 4
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 octets L -- Transfer Length in octets
E -- Encoding Symbol Length in octets E -- Encoding Symbol Length in octets
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:
I -- the number of larger source blocks. I -- the number of larger source blocks.
A_large -- the length of each of the larger source blocks in A_large -- the length of each of the larger source blocks in
symbols. symbols.
A_small -- the length of each of the smaller source blocks in A_small -- the length of each of the smaller source blocks in
skipping to change at page 24, line 46 skipping to change at page 19, line 47
Algorithm: Algorithm:
1. A_large = ceil[T/N] 1. A_large = ceil[T/N]
2. A_small = floor[T/N] 2. A_small = floor[T/N]
3. I = T - A_small * N 3. I = T - A_small * N
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 octets in length. Each of the symbols; each source symbol is E octets 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 octets in length except that the last source source symbol is E octets in length, except that the last source
symbol of the last source block is L-((L-1)/E) rounded down to the symbol of the last source block is L-((L-1)/E) rounded down to the
nearest integer)*E octets in length. nearest integer)*E octets 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 CDP MUST provide congestion control that control. Any complete CDP MUST provide congestion control that
conforms to [6], 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 CDP. 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 CDP that uses for the use of this FEC building block. However, any CDP that uses
the FEC building block may use other building blocks for example to the FEC building block may use other building blocks, for example, to
provide support for sending higher level session information within provide support for sending higher level session 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 at many receivers. This is the corrupted packet will arrive at 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 source authentication and integrity checking is thus RECOMMENDED that source authentication and integrity checking
are applied to decoded objects before delivering objects to an are applied to decoded objects before delivering objects to an
application. For example, a SHA-1 hash [7] of an object may be application. For example, a SHA-1 hash [7] of an object may be
appended before transmission, and the SHA-1 hash is computed and appended before transmission, and the SHA-1 hash is computed and
checked after the object is decoded but before it is delivered to an checked after the object is decoded, but before it is delivered to an
application. Source authentication SHOULD be provided, for example application. Source authentication SHOULD be provided, for example,
by including a digital signature verifiable by the receiver computed by including a digital signature verifiable by the receiver and
on top of the hash value. It is also RECOMMENDED that a packet computed on top of the hash value. It is also RECOMMENDED that a
authentication protocol such as TESLA [9] be used to detect and packet authentication protocol such as Timed Efficient Stream Loss-
discard corrupted packets upon arrival. Furthermore, it is Tolerant Authentication (TESLA) [9] be used to detect and discard
RECOMMENDED that Reverse Path Forwarding checks be enabled in all corrupted packets upon arrival. Furthermore, it is RECOMMENDED that
network routers and switches along the path from the sender to Reverse Path Forwarding checks be enabled in all network routers and
receivers to limit the possibility of a bad agent successfully switches along the path from the sender to receivers to limit the
injecting a corrupted packet into the multicast tree data path. 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 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
avoid these problems, it is RECOMMENDED that measures be taken to avoid these problems, it is RECOMMENDED that measures be taken to
prevent receivers from accepting incorrect session descriptions, prevent receivers from accepting incorrect session descriptions,
e.g., by using source authentication to ensure that receivers only e.g., by using source authentication to ensure that receivers only
accept legitimate session descriptions from authorized senders. accept legitimate session descriptions from authorized senders.
12. IANA Considerations 12. IANA Considerations
Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA
registration. They are registered in the registry named "Reliable registration. They are in the registry named "Reliable Multicast
Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs" Transport (RMT) FEC Encoding IDs and FEC Instance IDs" located at
located at time of publication at: time of publication at:
http://www.iana.org/assignments/rmt-fec-parameters http://www.iana.org/assignments/rmt-fec-parameters
FEC Encoding IDs and FEC Instance IDs are hierarchical: FEC Encoding FEC Encoding IDs and FEC Instance IDs are hierarchical: FEC Encoding
IDs scope independent ranges of FEC Instance IDs. Only FEC Encoding IDs scope independent ranges of FEC Instance IDs. Only FEC Encoding
IDs that correspond to Under-Specified FEC schemes scope a IDs that correspond to Under-Specified FEC schemes scope a
corresponding set of FEC Instance IDs. 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"
skipping to change at page 29, line 12 skipping to change at page 22, line 31
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. Changes from RFC3452 13. Changes from RFC3452
This section lists the changes between the Experimental version of This section lists the changes between the Experimental version of
this specification, [3], and this version: this specification, [3], and this version:
o The requirements for definition of a new FEC Scheme and the o The requirements for definition of a new FEC Scheme and the
requirements for specification of new Content Delivery Protocols requirements for specification of new Content Delivery Protocols
which use FEC Schemes are made more explicit to permit independent that use FEC Schemes are made more explicit to permit independent
definition of FEC Schemes and Content Delivery Protocols. definition of FEC Schemes and Content Delivery Protocols.
o The definitions of basic FEC Schemes have been removed with the o The definitions of basic FEC Schemes have been removed with the
intention of publishing these separately. intention of publishing these separately.
o The FEC Object Transmission Information is more explicitly defined o The FEC Object Transmission Information (OTI) is more explicitly
and in particular three classes of FEC OTI (Mandatory, Common and defined, and in particular, three classes of FEC OTI (Mandatory,
Scheme-specific) are introduced to permit re-usable definition of Common, and Scheme-specific) are introduced to permit reusable
explicit fields in Content Delivery Protocols to carry these definition of explicit fields in Content Delivery Protocols to
elements. carry these elements.
o FEC Schemes are required to specify a complete encoding for the o FEC Schemes are required to specify a complete encoding for the
FEC Object Transmission which can be carried transparently by FEC Object Transmission, which can be carried transparently by
Content Delivery protocols (instead of defining explicit Content Delivery protocols (instead of defining explicit
elements). elements).
o The possibility for FEC Schemes to define two FEC Payload ID o The possibility for FEC Schemes to define two FEC Payload ID
formats for use with source and repair packets respectively in the formats for use with source and repair packets, respectively, in
case of systematic FEC codes is introduced. the case of systematic FEC codes is introduced.
o The file blocking algorithm from FLUTE is included here as a o The file blocking algorithm from FLUTE is included here as a
common algorithm which is recommended to be re-used by FEC Schemes common algorithm that is recommended to be reused by FEC Schemes
when appropriate. when appropriate.
14. Acknowledgments 14. Acknowledgments
This document is largely based on RFC3452 [3] and thus thanks are due This document is largely based on RFC 3452 [3], and thus thanks are
to the additional authors of that document: J. Gemmell, L. Rizzo, M. due to the additional authors of that document: J. Gemmell, L. Rizzo,
Handley, J. Crowcroft. M. Handley, and J. Crowcroft.
15. References 15. References
15.1. Normative References 15.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] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, Considerations Section in RFCs", BCP 26, RFC 2434, October
October 1998. 1998.
15.2. Informative References 15.2. Informative References
[3] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., [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.
[4] 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.
[5] 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.
[6] 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.
[7] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [7] Federal Information Processing Standards Publication (FIPS PUB)
April 1992. 180-1, Secure Hash Standard, 17 April 1995.
[8] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, [8] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
"FLUTE - File Delivery over Unidirectional Transport", "FLUTE - File Delivery over Unidirectional Transport", RFC
RFC 3926, October 2004. 3926, October 2004.
[9] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, [9] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe,
"Timed Efficient Stream Loss-Tolerant Authentication (TESLA): "Timed Efficient Stream Loss-Tolerant Authentication (TESLA):
Multicast Source Authentication Transform Introduction", Multicast Source Authentication Transform Introduction", RFC
RFC 4082, June 2005. 4082, June 2005.
[10] 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
U.S.A. U.S.A.
Email: mark@digitalfountain.com EMail: mark@digitalfountain.com
Michael Luby Michael Luby
Digital Fountain Digital Fountain
39141 Civic Center Drive 39141 Civic Center Drive
Suite 300 Suite 300
Fremont, CA 94538 Fremont, CA 94538
U.S.A. U.S.A.
Email: luby@digitalfountain.com EMail: luby@digitalfountain.com
Lorenzo Vicisano Lorenzo Vicisano
Digital Fountain Digital Fountain
39141 Civic Center Drive 39141 Civic Center Drive
Suite 300 Suite 300
Fremont, CA 94538 Fremont, CA 94538
U.S.A. U.S.A.
Email: lorenzo@digitalfountain.com EMail: lorenzo@digitalfountain.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 33, line 45 skipping to change at page 25, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is currently provided by the
Administrative Support Activity (IASA). Internet Society.
 End of changes. 112 change blocks. 
270 lines changed or deleted 255 lines changed or added

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