One document matched: draft-ietf-fecframe-req-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "../../rfc2629.dtd" [
<!ENTITY fecbb SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5052.xml">
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<!--<?rfc strict="yes" ?>-->
<rfc category="info" docName="draft-ietf-fecframe-req-02" ipr="full3978">
<front>
<title abbrev="FECFRAME requirements">FECFRAME requirements</title>
<author fullname="Mark Watson" initials="M" surname="Watson">
<organization>Digital Fountain</organization>
<address>
<postal>
<street>39141 Civic Center Dr.</street>
<street>Suite 300</street>
<city>Fremont</city>
<region>CA</region>
<code>94538</code>
<country>US</country>
</postal>
<email>mark@digitalfountain.com</email>
</address>
</author>
<date month="December" year="2007" />
<area>Transport</area>
<workgroup>FECFRAME Working Group</workgroup>
<keyword>FEC</keyword>
<keyword>Forward Error Correction</keyword>
<keyword>Transport</keyword>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This document defines requirements for a "FEC Framework" to be
defined by the IETF FECFRAME working group. The object of this group is
primarily to develop specifications for using forward error correction
(FEC) codes with applications in the Internet to provide protection
against packet loss.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document defines requirements for a "FEC Framework" to be
defined by the IETF FECFRAME working group. The purpose of this working
group is defined in the working group charter as follows: <list>
<t>"The object of this group is to develop specifications for using
forward error correction (FEC) codes with applications in the
Internet to provide protection against packet loss. The group will
develop a protocol framework for application of FEC codes to
arbitrary packet flows over unreliable transport protocols over both
IP multicast and unicast."</t>
</list></t>
<t>This document defines requirements for this protocol framework. Both
'essential' ('SHALL') and 'non-essential' ('SHOULD') requirements are
considered.</t>
<t>A 'protocol framework' is a partial specification of a protocol,
along with a formal description of the missing aspects which are
required to form a full protocol specification - i.e. a protocol
framework is a protocol with 'holes' and a detailed description of the
'shape' of those holes. Protocol frameworks provide for maximum
commonality between different complete protocols which provide similar
functions and therefore simplify implementation and understanding of a
set of alternative protocols which perform similar functions. In this
case, support for different complete protocols is valuable for two
reasons. Firstly because there exist many different forward error
correction codes, with different properties in terms of error correction
capability, computational complexity, flexibility and intellectual
property rights. Secondly, there are many applications which could
benefit from the use of forward error correction. The FEC framework
therefore replaces the "full mesh" of application/FEC code combinations
with a single general approach which specifies how any FEC code meeting
the FEC code requirments defined in the framework can be used with any
application meeting the application requirements defined in the
framework.</t>
<t>The FEC protocol framework must therefore define as much as possible
of a protocol for providing forward error correction for arbitrary
packet flows over unreliable transport, without defining a particular
FEC code or assuming a particular application. Furthermore, the protocol
framework specification will define a clear interface between the
specified parts and the unspecified, FEC-code-specific and
application-specific, parts. For this purpose, the building block
techniques applied in the Reliable Multicast (RMT) working group will be
re-used, specifically the FEC Building Block <xref
target="RFC5052"></xref></t>
<t>The term "Forward Error Correction" refers here to
application/transport layer techniques for recovering lost packets of
data. More accurately, the term "Forward Erasure Correction" should be
used. In many contexts the term "Application Layer FEC (AL-FEC)" is also
used, although the mechanisms considered here could be considered as
either application or transport layer (the important point being that
they are end-to-end).</t>
<t>Generally, an "FEC Code" is defined in terms of the operations
required to construct encoded data from source data (at an encoder) and
to reconstruct source data from encoded data (at a decoder). In order to
apply an FEC Code to arbitrary packet flows, additional elements are
required such as protocol elements to identify encoded data within
packets, pre-processing of source data (e.g. segmentation and/or
addition of FEC-related indications into the source data). Therefore, in
order to adapt an FEC Code for use in the context of the FEC Framework,
additional FEC-code specific specification is required. Following the
approach of the FEC Building Block, this specification is known as an
"FEC Scheme". The FEC Framework will define the requirements that FEC
Schemes must meet for use with the framework.</t>
<t>Generally, it is required to add forward error correction to existing
applications, for example media streaming applications. In this case,
the application protocols must be extended to support this. The FEC
framework will describe the requirements that application protocols must
meet in order to be used with the FEC framework.</t>
</section>
<section title="Terminology">
<t><list style="hanging">
<t hangText="'FEC'">Forward Erasure Correction.</t>
<t hangText="'AL-FEC'">Application Layer Forward Erasure
Correction</t>
<t hangText="'FEC Framework'">The protocol framework which is to be
defined by FECFRAME and for which this document provides
requirements.</t>
<t hangText="'Source data flow'">The packet flow or flows to which
FEC protection is to be applied.</t>
<t hangText="'Repair data flow'">The packet flow or flows carrying
forward error correction data</t>
<t hangText="'Source protocol'">A protocol used for the source data
flow being protected - e.g. RTP.</t>
<t hangText="'Transport protocol'">The protocol used for transport
of the source data flow being protected - e.g. UDP, DCCP.</t>
<t hangText="'Control protocol'">Application layer protocols used to
establish and modify the source data flow being protected - e.g.
RTSP.</t>
<t hangText="'FEC Code'">An algorithm for encoding data such that
the encoded dats flow is resiliant to data loss or corruption.</t>
<t hangText="'FEC Scheme'">A specification which defines the
additional protocol aspects required to use a particular FEC code
with the FEC framework, or (in the context of RMT), with the RMT FEC
Building Block.</t>
<t hangText="'Source Block'">the group of source data packets which
are to be FEC protected as a single block</t>
<t hangText="'Protection amount'">The relative increase in data sent
due to the use of FEC.</t>
</list></t>
</section>
<section title="Motivation">
<t>One approach to the problem addressed in this document would be to
arrange the source packet flows into a sequence of 'objects' and then
apply FEC protection using the mechanisms defined by the RMT working
group for object transport. This section describes the motivation for
following a separate approach, although one that draws heavily on the
RMT work.</t>
<t>FEC Schemes defined according to the RMT FEC Building Block <xref
target="RFC5052"></xref> envisage objects with a
finite size. Mapping arbitrary flows to this environment one would need
to consider the flows as a sequence of such objects (also known as
Source Blocks). For each object, the RMT FEC Schemes expect FEC Object
Transmission Information to be communicated with the object. In many
cases some or all of this information will be the same for every block.
Thus there is some advantage in explicitly introducing the concept of a
flow (or bundle of flows) for which some or all of the FEC Object
Transmission Information can be the same for every source block. As well
as reducing overhead, it is advantageous to be able to inform the
receiver that these parameters won't change during the lifetime of the
flow or flows.</t>
<t>A second issue is that FEC Schemes in RMT generally also include
recommendations for parameter settings, which are based on single-object
delivery. Recommendations for protection of packet flows may be
different from these for a variety of reasons. There is a need,
therefore, for FEC-Scheme specific specification material which is
specific to the case of arbitrary packet flows and different from the
recommendations for single-object delivery. One of the key aspects of
the FEC Framework contemplated here is that it provides a context for
such material, in the form of an explicit description of the
requirements that FEC Schemes must meet in order to be used with this
framework.</t>
<t>A third issue is the question of how source data from a packet flow
or flows is formatted into data blocks that an 'object-based' FEC Scheme
could process. RMT FEC Schemes expect an object which is just a sequence
of bytes. We therefore would need to build such an object out of a
sequence of potentially variable-length source packets. There are
several ways this could be done and different FEC Schemes may require
different approaches. Again, the framework contemplated here provides a
context for the definition of these mechanisms through the concept of
FEC Schemes which are adapted for use with this framework. The RMT work
then envisages that both source packets and repair packets consist of
symbols which are extracted from or generated from (respectively) this
source block. In the case of FEC protection of arbitrary packet flows it
is desirable to support cases where the source packets are transmitted
unchanged, thereby providing backwards compatibility. This is not
compatible with in the RMT approach.</t>
<t>As a result of the considerations above, this document describes
requirements for an FEC Framework for arbitrary packet flows which is
independent of the RMT FEC Building Block, although we draw heavily on
the concepts developed there. FEC Schemes defined for use with this FEC
Framework are distinct from FEC Schemes defined for object delivery in
the context of the RMT FEC Building Block. However, it is expected that
in many cases the task of generalising an RMT FEC Scheme into one which
can be used with both the RMT protocols and this FEC Framework will be a
simple one.</t>
</section>
<section title="Essential requirements">
<t><list style="hanging">
<t hangText="Req-10:">The FEC Framework shall support a wide range
of FEC codes, using the abstractions of the FEC Building Block
defined in RMT <xref target="RFC5052"></xref>
(including short and long block FEC codes, systematic and
non-systematic codes). Specifically, the FEC Framework shall define
the requirements that FEC code specifications shall meet in order to
be used with the framework, re-using, as far as possible, the FEC
code specification approach and requirements from the FEC Building
Block and specifying any further requirements that must be met for
the FEC Framework.</t>
<t hangText="Req-20:">The FEC Framework shall support a wide range
of application protocols, using the abstractions of the FEC Building
Block <xref target="RFC5052"></xref>.
Specifically, the FEC Framework shall define the requirements that
application protocol specifications shall meet in order to be used
with the framework, re-using, as far as possible, the Content
Delivery Protocol specification approach and requirements from the
FEC Building Block and specifying any further requirements that must
be met for the FEC Framework.</t>
<t hangText="Req-30:">The FEC Framework shall support variable
source block sizes, including real-time variation of source block
size between blocks of a given source data flow.</t>
<t hangText="Req-35:">The FEC Framework shall support variable
protection amounts, including dynamic variation of protection amount
between blocks within a given source data flow.</t>
<t hangText="Req-40:">The FEC Framework shall be independent of the
source protocols (provided that source protocol uses one of the
supported transport protocols).</t>
<t hangText="Req-50:">The FEC Framework shall place minimal
requirements on the application protocols.</t>
<t hangText="Req-60:">The FEC Framework shall support variable
source data flow rates.</t>
<t hangText="Req-70:">The FEC Framework shall support variable
source data flow packet sizes.</t>
<t hangText="Req-80:">The FEC Framework shall provide support of
combined protection of multiple source data flows.</t>
<t hangText="Req-90:">The FEC Framework shall provide support of
multiple transport protocols for the source data protocols (UDP,
DCCP, others ?).</t>
<t hangText="Req-100:">The FEC Framework shall provide support for
definition of backwards-compatible FEC protocols (i.e. where the
source packets are not modified in any way).</t>
<t hangText="Req-110:">The FEC Framework shall provide support for
different source data protocols (RTP, MIKEY, others ?).</t>
<t hangText="Req-120:">The FEC Framework shall shall address the
security issues, if any, associated with the use of FEC.</t>
</list></t>
</section>
<section title="Non-essential requirements">
<t><list>
<t hangText="Req-12:">The FEC Framework should be constructed such
that the FEC streaming protocol defined by 3GPP in TS26.346 is a
valid protocol according to the FEC Framework.</t>
</list></t>
</section>
<section title="Security Considerations">
<t>This document defines requirements for the work of the FECFRAME
working group and includes a requirement that the security implications
of the use of FEC, if any, should be addressed in that work.</t>
</section>
</middle>
<back>
<references title="References">
&fecbb;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:54:39 |