One document matched: draft-roca-rmt-newfcast-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- $Id: draft-roca-rmt-newfcast-04.xml,v 1.2 2009-03-06 11:02:20 roca Exp $ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!--<rfc category="exp" docName="draft-roca-rmt-newfcast-03" ipr="full3978">-->
<rfc category="exp" ipr="pre5378Trust200902">
<!--
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
-->
<?xml-stylesheet type='text/xsl'
href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="FCAST: Scalable Object Delivery">FCAST: Scalable Object
Delivery for the ALC and NORM Protocols</title>
<author fullname="Vincent Roca" initials="V." surname="Roca">
<organization>INRIA</organization>
<address>
<postal>
<street>655, av. de l'Europe</street>
<street>Inovallee; Montbonnot</street>
<city>ST ISMIER cedex</city>
<code>38334</code>
<country>France</country>
</postal>
<email>vincent.roca@inria.fr</email>
<uri>http://planete.inrialpes.fr/people/roca/</uri>
</address>
</author>
<author fullname="Brian Adamson" initials="B." surname="Adamson">
<organization>Naval Research Laboratory</organization>
<address>
<postal>
<street></street>
<city>Washington, DC</city>
<code>20375</code>
<country>USA</country>
</postal>
<email>adamson@itd.nrl.navy.mil</email>
<uri>http://cs.itd.nrl.navy.mil</uri>
</address>
</author>
<date day="9" month="March" year="2009" />
<area>Transport</area>
<workgroup>RMT</workgroup>
<keyword>ALC, NORM</keyword>
<abstract>
<t>This document introduces the FCAST object (e.g., file) delivery
application on top of the ALC and NORM reliable multicast protocols.
FCAST is a highly scalable application that provides a reliable object
delivery service.</t>
</abstract>
</front>
<middle>
<!--
<t>
<list style="empty">
<t> *** Editor's note:
XXX </t>
</list>
</t>
-->
<section anchor="intro" title="Introduction">
<t>This document introduces the FCAST reliable and scalable object
(e.g., file) delivery application. Two versions of FCAST exist: <list
style="symbols">
<t>FCAST/ALC that relies on the Asynchronous Layer Coding (ALC)
<xref target="RMT-PI-ALC"></xref> and the Layered Coding Transport
(LCT) <xref target="RMT-BB-LCT"></xref> reliable multicast transport
protocol, and</t>
<t>FCAST/NORM that relies on the NACK-Oriented Reliable Multicast
(NORM) <xref target="RMT-PI-NORM"></xref> reliable multicast
transport protocol.</t>
</list> Hereafter, the term FCAST denotes either FCAST/ALC or
FCAST/NORM.</t>
<t>Depending on the target use case, the delivery service provided by
FCAST is more or less reliable. For instance, with FCAST/ALC used in
ON-DEMAND mode over a time period that largely exceeds the typical
download time, the service can be considered as fully reliable.
Similarly, when FCAST is used along with a session control application
that collects reception information and takes appropriate corrective
measures (e.g., a direct point-to-point retransmission of missing
packets, or a new multicast recovery session), then the service can be considered
as fully reliable. On the opposite, if FCAST operates in PUSH mode, then
the service is usually only partially reliable, and a receiver that is
disconnected during a sufficient time will perhaps not have the
possibility to download the object.</t>
<t>Depending on the target use case, the FCAST scalability is more or
less important. For instance, if FCAST/ALC is used on top of purely
unidirectional transport channels, with no feedback information at all,
which is the default mode of operation, then the scalability is maximum
since neither FCAST, nor ALC, UDP or IP generates any feedback message.
On the opposite, the FCAST/NORM scalability is typically limited by NORM
scalability itself. Similarly, if FCAST is used along with a session
control application that collects reception information from the
receivers, then this session control application limits the scalability
of the global object delivery system. This situation can of course be
mitigated by using a hierarchy of feedback message aggregators or
servers. The details of this is out of the scope of the present
document.</t>
<t>A design goal behind FCAST is to define a streamlined solution, in
order to enable lightweight implementations of the protocol stack, and
limit the operational processing and storage requirements. A consequence
of this choice is that FCAST cannot be considered as a versatile
application, capable of addressing all the possible use-cases. On the
opposite, FCAST has some intrinsic limitations. From this point of view
it differs from FLUTE <xref target="RMT-FLUTE"></xref> which favors
flexibility at the expense of some additional complexity.</t>
<t>A good example of the design choices meant to favor the
simplicity is the way FCAST manages the object meta-data: by default,
the meta-data and the object content are sent together, in a compound
object. This solution has many advantages in terms of simplicity as will
be described later on.
However, as such, it also has an intrinsic limitation since it does not enable
a receiver to decide in advance, before beginning the reception of the
compound object, whether the object is of interest or not, based on the
information that may be provided in the meta-data.
Therefore this document defines additional techniques that may be used
to mitigate this limitation.
It is also possible that some use-cases require that each receiver
download the whole set of objects sent in the session (e.g., with
mirroring tools). When this is the case, the above limitation is no
longer be a problem.</t>
<section anchor="applicability" title="Applicability">
<!-- ==================================== -->
<t>FCAST is compatible with any congestion control protocol designed
for ALC/LCT or NORM. However, depending on the use-case, the data flow
generated by the FCAST application might not be constant, but instead
be bursty in nature. Similarly, depending on the use-case, an FCAST
session might be very short. Whether and how this will impact the
congestion control protocol is out of the scope of the present
document.</t>
<t>FCAST is compatible with any security mechanism designed for
ALC/LCT or NORM. The use of a security scheme is strongly RECOMMENDED
(see <xref target="security"></xref>).</t>
<t>FCAST is compatible with any FEC scheme designed for ALC/LCT or
NORM. Whether FEC is used or not, and the kind of FEC scheme used, is
to some extent transparent to FCAST.</t>
<t>FCAST is compatible with both IPv4 and IPv6. Nothing in the FCAST
specification has any implication on the source or destination IP
address.</t>
</section>
</section>
<section title="Requirements notation">
<!-- ==================================== -->
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Definitions, Notations and Abbreviations">
<!-- ================================================= -->
<section title="Definitions">
<!-- ==================== -->
<t>This document uses the following definitions: <list style="empty">
<t>FCAST/ALC denotes the FCAST application running on top of the
ALC/LCT reliable transport protocol;</t>
<t>FCAST/NORM denotes the FCAST application running on top of the
NORM reliable transport protocol;</t>
<t>FCAST denotes either FCAST/ALC or FCAST/NORM;</t>
<t>Compound Object denotes an ALC or NORM transport object
composed of the Compound Object Header <xref
target="header_format"></xref>, including any meta-data and the
content of the original application object (e.g., a file);</t>
<t>Carousel denotes the compound object transmission system of an
FCAST sender;</t>
<t>Carousel Instance denotes a fixed set of registered compound
objects that are sent by the carousel during a certain number of
cycles. Whenever compound objects need to be added or removed, a
new Carousel Instance is defined;</t>
<t>Carousel Instance Object (CIO) denotes a specific object that
lists the compound objects that comprise a given carousel
instance;</t>
<t>Carousel Cycle denotes a transmission round within which all
the compound objects registered in the Carousel Instance are
transmitted a certain number of times. By default, compound
objects are transmitted once per cycle, but higher values are
possible, that might differ on a per-object basis;</t>
<t>The Transmission Object Identifier (TOI) refers the numeric
identifier associated to a specific object by the underlying
transport layer. In the case of ALC, this corresponds to the TOI
described in that specification while for the NORM specification
this corresponds to the NormObjectId described there.</t>
</list></t>
</section>
<section title="Abbreviations">
<!-- ====================== -->
<t>This document uses the following abbreviations:</t>
<texttable>
<ttcol width="25%">Abbreviation</ttcol>
<ttcol align="left">Definition</ttcol>
<c>CIO</c>
<c>Carousel Instance Object</c>
<c>FEC OTI</c>
<c>FEC Object Transmission Information</c>
<c>TOI</c>
<c>Transmission Object Identifier</c>
</texttable>
</section>
</section>
<section anchor="fcast_principles" title="FCAST Principles">
<!-- ==================================== -->
<section anchor="fcast_service" title="FCAST Content Delivery Service">
<!-- ==================================== -->
<t>The basic goal of FCAST is to transmit objects to a group of
receivers in a reliable way. The receiver set MAY be restricted to a
single receiver or MAY include possibly a very large number of
receivers. FCAST is specified to support two forms of operation.<list
style="numbers">
<t>FCAST/ALC: where the FCAST application is meant to run on top
of the ALC/LCT reliable multicast transport protocol, and</t>
<t>FCAST/NORM: where the FCAST application is meant to run on top
of the NORM reliable multicast transport protocol.</t>
</list></t>
<t>This specification is designed such that both forms of operation
share as much commonality as possible.</t>
<t>While the choice of the underlying transport protocol (i.e., ALC or
NORM) and its parameters may limit the practical receiver group size,
nothing in FCAST itself limits it. The transmission might be fully
reliable, or only partially reliable depending upon the way ALC or
NORM is used (e.g., whether FEC encoding and/or NACK-based repair
requests are used or not), the way the FCAST carousel is used (e.g.,
whether the objects are made available for a long time span or not),
and the way in which FCAST itself is employed (e.g., whether there is
a session control application that might automatically extend an
existing FCAST session until all receivers have received the
transmitted content).</t>
<t>FCAST is designed to be as self-sufficient as possible, in
particular in the way object meta-data is attached to object data
content. However, for some uses, meta-data MAY also be communicated by
an out-of-band mechanism that is out of the scope of the present
document.</t>
</section>
<section anchor="meta-data_tx" title="Meta-Data Transmission">
<!-- ==================================== -->
<t>FCAST usually carries meta-data elements by prepending them to the
object it refers to. As a result, a compound object is created that is
composed of a header followed by the original object content. This
header is itself composed of the meta-data as well as several fields,
for instance to indicate the boundaries between the various parts of
this compound object (<xref target="fig_compound_obj"/>).</t>
<figure anchor="fig_compound_obj" title="Compound Object composition.">
<artwork align="center"><![CDATA[
<------------------------ Compound Object ----------------------->
+-------------------------+--------------------------------------+
| Compound Object Header | Object Content |
| (can include meta-data) | (can be encoded by FCAST) |
+-------------------------+--------------------------------------+
]]></artwork>
</figure>
<t>Attaching the meta-data to the object is an efficient solution,
since it guaranties that meta-data be received along with the
associated object, and it allows the transport of the meta-data to
benefit from any transport-layer FEC erasure protection of the
compound object. However a limit of this scheme, as such, is that a
client does not know the meta-data of an object before begining
its reception, and (in case of erasures) perhaps not until the object
decoding is completed. The details of course depend upon the transport
protocol and the FEC code used.</t>
<t>In certain use-cases, FCAST can also be associated to another in-band
(e.g., via NORM INFO messages, <xref target="norm_specifics"></xref>) or
out-of-band signaling mechanism. In that case, this mechanism can be used
in order to carry the whole meta-data (or a subset of it), possibly ahead
of time.</t>
</section>
<section anchor="meta-data_content" title="Meta-Data Content">
<!-- ==================================== -->
<t>The meta-data associated to an object can be composed of, but are
not limited to: <list style="symbols">
<t>Content-Location: the URI of the object, which gives the name
and location of the object;</t>
<t>Content-Type: the MIME type of the object;</t>
<t>Content-Length: the size of the initial object, before any
content encoding (if any). Note that this content length does not
include the meta-data nor the fixed size compound object header;</t>
<t>Content-Encoding: the optional encoding of the object performed
by FCAST. If there is no Content-Encoding entry, the receiver MUST
assume that the object is not encoded (default). The support of gzip
encoding, or any other solution, remains optional.</t>
<!--
<t> the size of the object after the optional encoding performed by FCAST; </t>
<t> a timestamp associated to this object; </t>
<t> Expires: the time validity of the object, after which the object is considered
as out-of-date; </t>
-->
<t>Content-MD5: the MD5 message digest of the object in order to
check its integrity. Note that this digest is meant to protect
from transmission and processing errors, not from deliberate
attacks by an intelligent attacker. Note also that this digest
only protects the object, not the header, and therefore not the
meta-data;</t>
<t>a digital signature for this object;</t>
</list></t>
<t>This list is not limited and new meta-data information can be
added. For instance, when dealing with very large objects (e.g., that
largely exceed the working memory of a receiver), it can be
interesting to split this object into several sub-objects. When a file
is split into several objects by FCAST, the meta-data includes: <list
style="symbols">
<t>Fcast-Obj-Slice-Nb: the total number of slices. A value
strictly greater than 1 indicates that this object is the result
of a split of the original object;</t>
<t>Fcast-Obj-Slice-Idx: the slice index (in the [0 .. SliceNb[
interval);</t>
<t>Fcast-Obj-Slice-Offset: the offset at which this slice starts
within the original object;</t>
</list></t>
<t>When meta-data elements are communicated out-of-band, in advance of
data transmission, the following pieces of information may also be
useful: <list style="symbols">
<t>TOI: the Transmission Object Identifier (TOI) of the object
(<xref target="object_id"></xref>), in
order to enable a receiver to easily associate the meta-data to
the object for which he receives packets;</t>
<t>FEC Object Transmission Information (FEC OTI). In this case the
FCAST sender does not need to use the optional EXT_FTI mechanism
of ALC or NORM protocols.</t>
</list></t>
</section>
<section anchor="carousel" title="Carousel Transmission">
<!-- ==================================== -->
<t>A set of FCAST compound objects scheduled for transmission are
considered a logical "Carousel". A single "Carousel Instance" is
comprised of a fixed set of compound objects. Whenever the FCAST
application needs to add new compound objects to or remove old
compound objects from the transmission set, a new Carousel Instance
is defined since the set of compound objects changes.</t>
<t>For a given Carousel Instance, one or more transmission cycles are
possible. During each cycle, all of the compound objects comprising
the Carousel are sent. By default, each object is transmitted once per
cycle. However, in order to allow different levels of priority, some
objects MAY be transmitted more often that others during a cycle,
and/or benefit from higher FEC protection than others. This can be the
case for instance of the CIO objects (<xref target="cio"></xref>). For
some FCAST usage (e.g., a unidirectional "push" mode), a Carousel
Instance may be associated to a single transmission cycle. In other cases
it may be associated to a large number of transmission cycles (e.g., in
"on-demand" mode, where objects are made available for download during
a long period of time).</t>
</section>
<section anchor="cio" title="Carousel Instance Object">
<!-- ==================================== -->
<t>The FCAST sender CAN transmit an OPTIONAL Carousel Instance Object
(CIO). The CIO carries the list of the compound objects that are part of
a given Carousel Instance, by specifying their
respective Transmission Object Identifiers (TOI). However the CIO does
not describe the objects themselves (i.e., there is no meta-data).
Additionally, the CIO includes a "Complete" flag that is used to
indicate that no further modification to the enclosed list will be done
in the future. Finally, the CIO includes a Carousel Instance ID that
identifies the Carousel Instance it pertains to.</t>
<t> There is no reserved TOI value for the CIO itself, since this object
is regarded by ALC/LCT or NORM as a standard object. On the opposite,
the nature of this object (CIO) is indicated by means of a specific
compound object header field (the "I" flag) so that it can be recognized
and processed by the FCAST
application as needed. A direct consequence is the following: since a
receiver does not know in advance which TOI will be used for the following
CIO (i.e., with dynamic sessions), he MUST NOT filter out packets that
are not in the CIO's TOI list. Said differently, the goal of CIO is not
to setup ALC or NORM packet filters (this mechanism would not be secure
in any case).</t>
<t>The use of a CIO remains optional. If it is not used, then the
clients progressively learn what files are part of the carousel
instance by receiving ALC or NORM packets with new TOIs. However using
a CIO has several benefits:
<list style="symbols">
<t>When the "Complete" flag is set (if ever), the receivers know
when they can leave the session, i.e., when they have received all
the objects that are part of the delivery session;</t>
<t>In case of a session with a dynamic set of objects, the sender
can reliably inform the receivers that some objects have been
removed from the carousel with the CIO. This solution is more
robust than the "Close Object flag (B)" of ALC/LCT since a client
with an intermittent connectivity might loose all the packets
containing this B flag. And while NORM provides a robust object
cancellation mechanism in the form of its NORM_CMD(SQUELCH)
message in response to receiver NACK repair requests, the use of
the CIO provides an additional means for receivers to learn of
objects for which it is futile to request repair;</t>
</list>
</t>
<t>
During idle periods, when the carousel instance does not contain
any object, a CIO with an empty TOI list MAY be transmitted.
In that case, a new carousel instance ID MUST be used to differentiate
this (empty) carousel instance from the other ones.
This mechanism can be useful to inform the receivers that:
<list style="symbols">
<t>all the previously sent
objects have been removed from the carousel. It therefore
improves the FCAST robustness even during "idle" period;</t>
<t>the session is still active even
if there is currently no content being sent. Said differently,
it can be used as a heartbeat mechanism.
If the "Complete" flag has not been set, it implicitly informs
the receivers that new objects may be sent in the future;</t>
</list>
</t>
<t>The decisions of whether a CIO should be used or not, how often
and when a CIO should be sent, are left to the sender and depend on many
parameters, including the target use case and the session dynamics.
For instance it may be appropriate to send a CIO at the beginning of
each new carousel instance, and then periodically. These
operational aspects are out of the scope of the present document.</t>
</section>
<section anchor="object_id" title="Compound Object Identification">
<!-- ==================================== -->
<t>The FCAST compound objects are directly associated with the object-based
transport service that the ALC and NORM protocols provide. In each of
these protocols, the messages containing transport object content are
labeled with a numeric transport object identifier (i.e., the ALC TOI
and the NORM <spanx style="emph">NormTransportId</spanx>). For
purposes of this document, this identifier in either case (ALC or
NORM) is referred to as the TOI.
<!--
The FCAST Compound Object Header
meta-data can include an attribute that identifies the given object's
TOI. Additionally, the CIO lists objects for the applicable Carousel
Instance by using the TOI.
-->
</t>
<t>
There are several differences between ALC and NORM:
<list style="symbols">
<t>the ALC use of TOI is rather flexible, since several TOI
field sizes are possible (from 16 to 112 bits), this size can
be changed at any time, on a per-packet basis, and their management
is totally free as long as each object is associated to a unique
TOI (if no wraparound happened);</t>
<t>the NORM use of TOI is more directive, since the TOI field
is 16 bits long and TOIs MUST be managed sequentially;</t>
</list>
</t>
<t>In both NORM and ALC, it is possible that the transport
identification space may eventually wrap for long-lived sessions
(especially with NORM where this phenomenon is expected to happen
more frequently).
This can possibly introduce some ambiguity in FCAST object
identification if a sender retains some older objects in newer
Carousel Instances with updated object sets. Thus, when an updated
object set for a new Carousel Instance transport identifiers that
exceed one-half of the TOI sequence space (or otherwise exceed the
sender repair window capability in the case of NORM) it may be
necessary to re-enqueue old objects within the Carousel with new TOI
to stay within transport identifier limits. To allow receivers to
properly combine new transport symbols for any older objects with
newly-assigned TOIs to achieve reliable transfer, a mechanism is
required to equate the object(s) with new TOI with the older object
TOI.</t>
<t><list style="empty">
<t><spanx style="emph">*** Editor's note:
This mechanism is TBD. Two complementary possibilities are:
(1) if the meta-data are processed rapidly (e.g., by using
NORM-INFO messages), a receiver quickly detects that both
objects are the same and take appropriate measures;
(2) we can also add a way, in the CIO, to say that
{TOI, current CI} == {prev_TOI, prev CI}.
</spanx></t>
</list></t>
</section>
<section anchor="alc_specifics"
title="FCAST/ALC Additional Specificities">
<!-- ==================================== -->
<t>There are no additional detail or option for FCAST/ALC
operation.</t>
</section>
<section anchor="norm_specifics"
title="FCAST/NORM Additional Specificities">
<!-- ==================================== -->
<t>The NORM Protocol provides a few additional capabilities that can
be used to specifically support FCAST operation:</t>
<t><list style="numbers">
<t>The NORM_INFO message for conveying "out-of-band" content with
respect to a given transport object MAY be used to provide the
compound object header, and in particular the object meta-data,
to the receivers.
Note that the availability of NORM_INFO for a given object is signaled
through the use of a dedicated flag in the NORM_DATA message header.
Additionally, NORM's NACK-based repair request signaling allows
a receiver to request separately and quickly an object's NORM_INFO
content.
<!--
(that is typically encoded using FEC).
-->
However, the limitation here is that the Compound
Object Header and its meta-data MUST fit within the byte size
limit defined by the NORM sender's configured "segment size"
(typically a little less than the network MTU);</t>
<t>The NORM_CMD(SQUELCH) messages are used by the NORM protocol
sender to inform receivers of objects that have been canceled when
receivers make repair requests for such invalid objects.
Along with the CIO mechanism, a receiver has an efficient and
reliable way to discover old objects that have been removed from the
carousel instance;
</t>
<t>NORM also supports an optional positive acknowledgment
mechanism that can be used for small-scale multicast receiver
group sizes. Also, it may be possible in some cases for the sender
to infer, after some period without receiving NACKs at the end of
its transmission that the receiver set has fully received the
transmitted content. In particular, if the sender completes its
end-of-transmission series of NORM_CMD(FLUSH) messages without
receiving repair requests from the group, it may have some
assurance that the receiver set has received the content prior to
that point. These mechanisms are likely to help FCAST in achieving
fully reliable transmissions;</t>
</list></t>
<t>
When NORM_INFO is used with FCAST/NORM, the NORM_INFO content MUST
contain the FCAST Compound Object Header and meta-data for that
object, or a subset of the meta-data.
In this case, the compound object sent in the regular NORM_DATA packets
MAY be streamlined in order to contain no meta-data at all, or only the
subset of the meta-data that is not carried in the NORM_INFO message.
</t>
<!--
<t>Receivers automatically learn of the availability of NORM_INFO for
a given object from a flag in the NORM_DATA message header. When
NORM_INFO is used for FCAST/NORM operation, the NORM_INFO content MUST
contain the FCAST Compound Object Header and meta-data for that
object. In this case, the data content portion of the NORM transport
object is the original application object. When NORM_INFO is not used
for a given sender object (i.e., the corresponding NORM_DATA header
flag is not set), the NORM transport object data content sent MUST
contain the FCAST Compound Object Header unless this information is
signaled by another means (out of scope of this document) prior to the
carousel transmission.</t>
-->
<t>It should also be noted that the NORM_INFO message header may carry
the EXT_FTI extension. The reliable delivery of the NORM_INFO content
allows the individual objects' FEC Transmission Information to be
provided to the receivers without burdening every packet (i.e.
NORM_DATA messages) with this additional, but important, content.
Examples are provided in <xref target="fcast_exple"></xref>.
</t>
</section>
<section anchor="sender_behavior" title="FCAST Sender Behavior">
<!-- ==================================== -->
<t>The following operations take place at a sender: <list
style="numbers">
<t>The user (or another application) selects a set of objects
(e.g., files) to deliver and submits them, along with their
meta-data, to the FCAST application;
<!--
The user MAY also specify how many times each object
should be sent in this carousel instance during a cycle (by default,
each object will be sent once). Said differently, if
objects have similar lengths, assigning them a different number of
transmissions leads to define different transmission priorities to
each of them;
-->
</t>
<t>For each object, FCAST creates the compound object and
registers this latter in the carousel instance.</t>
<t>The user then informs FCAST when all the objects of the set
have been submitted. If the user knows that no new object will
be submitted in the future (i.e., if the session's content is now
complete), the user informs FCAST.
Finally, the user specifies how many transmission cycles are
desired (this number may be infinite);</t>
<t>At this point, the FCAST application knows the full list of
compound objects that are part of the carousel instance and can
create a CIO if desired, possibly with the complete flag set;
</t>
<t>
The FCAST application can now define a transmission schedule of
these compound objects, including the optional CIO(s).
This schedule defines in which order the packets of the various
compound objects should be sent.
This document does not specify any scheme. This is left to the
developer within the provisions of the underlying ALC or NORM
protocol used and the knowledge of the target use-case.</t>
<t>The FCAST application then starts the carousel transmission,
for the number of cycles specified. Transmissions take
place until: <list
style="symbols">
<t>the desired number of transmission cycles has been reached,
or</t>
<t>the user wants to prematurely stop the transmissions,
or</t>
<t>the user wants to add one or several new objects to the
carousel, or on the opposite wants to remove old objects from
the carousel. In that case a new carousel instance must be
created.</t>
</list> Then continue at Step 1 above.</t>
</list></t>
</section>
<section anchor="receiver_behavior" title="FCAST Receiver Behavior">
<!-- ==================================== -->
<t>The following operations take place at an FCAST receiver: <list
style="numbers">
<t>The receiver joins the session and collects symbols;</t>
<t>If the header portion of a compound object is entirely received
(which may happen before receiving the entire object with some
ALC/NORM transport configurations), the receiver processes the
meta-data and chooses to continue to receive the object content
or not;</t>
<t>When a compound object has been entirely received, the receiver
processes the header, retrieves the object meta-data, perhaps
decodes the meta-data, and processes the object accordingly;</t>
<t>When a CIO is received, which is indicated by the 'I' flag set
in the compound object header, the receiver decodes the CIO, and
retrieves the list of objects that are part of the current
carousel instance. This list CAN be used to remove objects sent in a
previous carousel instance that might not have been totally
decoded and that are no longer part of the current carousel
instance;</t>
<t>When a receiver has received a CIO with the "Complete" flag
set, and has successfully received all the objects of the current
carousel instance, it can safely exit from the current FCAST
session;</t>
<t>Otherwise continue at Step 2 above.</t>
</list></t>
</section>
</section>
<section anchor="fcast_specifications" title="FCAST Specifications">
<!-- ==================================== -->
<t>This section details the technical aspects of FCAST.</t>
<section anchor="header_format" title="Compound Object Header Format">
<!-- ==================================== -->
<t>In an FCAST session, compound objects are constructed by
prepending the Compound Object Header (which may include meta-data)
before the original object data content
(<xref target="header_with_md_format"></xref>).</t>
<figure anchor="header_with_md_format"
title="Compound Object Header with Meta-Data.">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
|rsv|G|I|MDF|MDE| Header Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Checksum | | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d
| Object Meta-Data (optional, variable length) | r
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Padding (optional) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
| |
. Object Data (optional, variable length) .
. .
. .]]></artwork>
</figure>
<t>The Compound Object Header fields are:</t>
<texttable>
<ttcol align="right" width="15%">Field</ttcol>
<ttcol align="left">Description</ttcol>
<c>Reserved</c>
<c>2-bit field set to 0 in this specification and reserved for
future use.</c>
<c>G</c>
<c>1-bit field that, when set to 1, indicates that the checksum
encompasses the whole compound object (Global checksum).
When set to 0, this field indicates that the checksum encompasses
only the compound object header.</c>
<c>I</c>
<c>1-bit field that, when set to 1, indicates the object is a
Carousel Instance Object (CIO). When set to 0, this field indicates
that the transported object is a standard object.</c>
<c>Meta-Data Format (MDFmt)</c>
<c>2-bit field that defines the format of the object meta-data (see
<xref target="iana"></xref>). An HTTP/1.1 metainformation format
<xref target="RFC2068"></xref> MUST be supported and is associated
to value 0. Other formats (e.g., XML) MAY be defined in the
future.</c>
<c>Meta-Data Encoding (MDEnc)</c>
<c>2-bit field that defines the optional encoding of the Object
Meta-Data field (see <xref target="iana"></xref>). By default, a
plain text encoding is used and is associated to value 0. Gzip
encoding MUST also be supported and is associated to value 1. Other
encodings MAY be defined in the future.</c>
<c>Header Length</c>
<c>24-bit field indicating total length (in bytes) of all fields of
the Compound Object Header, except the optional padding. A header
length field set to value 6 means that there is no meta-data
included. When this size is not multiple to 32 bits words, padding
is added. It should be noted that the meta-data field maximum size
is equal to 2^24 - 6 bytes.</c>
<c>Checksum</c>
<c>16-bit field that contains the checksum computed over either
the whole compound object (when G is set to 1), or over the
compound object header (when G is set to 0), using the algorithm
specified for TCP in RFC793. More precisely,
the checksum field is the 16 bit one's complement of the one's
complement sum of all 16 bit words to be considered. If a
segment contains an odd number of octets to be
checksummed, the last octet is padded on the right with zeros to
form a 16 bit word for checksum purposes (this pad is not
transmitted). While computing the checksum, the checksum field
itself is set to zero.
</c>
<c>Object Meta-Data</c>
<c>Optional, variable length field that contains the meta-data
associated to the object, either in plain text or encoded, as
specified by the MDEnc field. The Meta-Data is NULL-terminated plain
text that follows the "TYPE" ":" "VALUE" "<CR-LF>" format used in
HTTP/1.1 for metainformation <xref target="RFC2068"></xref>. The
various meta-data items can appear in any order. The associated
string, when non empty, MUST be NULL-terminated. When no meta-data
is communicated, this field MUST be empty.</c>
<c>Padding</c>
<c>Optional, variable length field of zero-value bytes to align
the start of the object data content to 32-bit boundary. Padding is only
used when the header length value, in bytes, is not multiple of
4.</c>
</texttable>
<t>The Compound Object Header is then followed by the Object Data,
i.e., the original object possibly encoded by FCAST. Note that the length
of this content is the transported object length (e.g., as specified by the
FEC OTI) minus the Header Length.
</t>
</section>
<section anchor="carousel_instance_object"
title="Carousel Instance Object Format">
<!-- ==================================== -->
<t>The format of the CIO, which is a particular compound object, is
given in <xref target="cio_format"></xref>.</t>
<figure anchor="cio_format" title="Carousel Instance Object Format.">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
|rsv|G|1|MDF|MDE| Header Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Checksum | | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d
| Object Meta-Data (optional, variable length) | r
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Padding (optional) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
. . ^
. Object List (variable length) . |
. . o
. +-+-+-+-+-+-+-+-+ b
. | j
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v ]]></artwork>
</figure>
<t>Because the CIO is transmitted as a special compound object, the
following CIO-specific meta-data entries are defined:
<list style="symbols">
<t>Fcast-CIO-Complete: when set to 1, it indicates that no new
objects in addition to the ones whose TOI are specified in this
CIO, or the ones that have been specified in the previous CIO(s),
will be sent in the future;</t>
<t>Fcast-CIO-ID: this value identifies the carousel instance. It
starts from 0 and is incremented by 1 for each new carousel
instance. This entry is not mandatory since the TOI numbering of
the compound objects carrying a CIO can be used to identify the
latest CIO instance. However, this value can be useful to detect
possible gaps in the carousel instances, for instance caused by
long disconnection periods. It can also be useful to avoid
problems when TOI wrapping to 0 takes place.</t>
</list></t>
<t>Additionally, the following standard meta-data entries are often
used (<xref target="meta-data_content"/>):
<list style="symbols">
<t>Content-Length: it specifies the size of the object list, before any
content encoding (if any).</t>
<t>Content-Encoding: it specifies the optional encoding of the object
list, performed by FCAST. For instance:
<figure>
<artwork align="left"><![CDATA[ Content-Encoding: gzip ]]></artwork>
</figure>
indicates that the Object List field has been encoded
with gzip <xref target="RFC1952"></xref>. If there is no Content-Encoding
entry, the receiver MUST assume that the Object List field is plain text
(default). The support of gzip encoding, or any other solution, remains optional.</t>
</list>
</t>
<t>An empty Object List is valid and indicates that the current carousel
instance does not include any object (<xref target="cio"/>).
This can be specified by using the following meta-data entry:
<figure>
<artwork align="left"><![CDATA[ Content-Length: 0 ]]></artwork>
</figure>
or simply by leaving the Object List empty. In the latter case, the
transported object length (e.g., as specified by the FEC OTI) minus the
Header Length equals zero.
</t>
<t>The non-encoded (i.e., plain text) Object List, when non empty, is a
NULL-terminated ASCII string. It contains the list of TOIs included in
the current carousel instance, specified either as the individual TOIs
of each object, or as TOI intervals, or any combination. The format
of the ASCII string is a comma-separated list of individual "TOI"
values or "TOI_a-TOI_b" elements. This latter case means that all
values between TOI_a and TOI_b, inclusive, are part of the list. We
further require that TOI_a be strictly inferior to TOI_b.
If a TOI wrapping to 0 occurs in an interval, then two TOI intervals
MUST be specified, TOI_a-MAX_TOI and 0-TOI_b.
</t>
<t>The ABNF specification is the following:</t>
<figure>
<artwork align="left"><![CDATA[cio-list = *(list-elem *( "," list-elem))
list-elem = toi-value / toi-interval
toi-value = 1*DIGIT
toi-interval = toi-value "-" toi-value
; additionally, the first toi-value MUST be
; strictly inferior to the second toi-value
DIGIT = %x30-39
; a digit between O and 9, inclusive]]></artwork>
</figure>
<t>For processing reasons, all the TOI values in the list MUST be given
in increasing order. However a receiver MUST be able to handle
non-monotonically increasing values. Furthermore, a given TOI value MUST NOT
be included multiple times in the list.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<!-- ==================================== -->
<!-- XXX: this section is taken from FLUTE. It is therefore very ALC centric... -->
<section anchor="pb_statement" title="Problem Statement">
<!-- ==================================== -->
<t>A content delivery system is potentially subject to attacks.
Attacks may target: <list style="symbols">
<t>the network (to compromise the routing infrastructure, e.g., by
creating congestion),</t>
<t>the Content Delivery Protocol (CDP) (e.g., to compromise the
normal behavior of FCAST) or</t>
<t>the content itself (e.g., to corrupt the objects being
transmitted).</t>
</list></t>
<t>These attacks can be launched either: <list style="symbols">
<t>against the data flow itself (e.g., by sending forged
packets),</t>
<t>against the session control parameters (e.g., by corrupting the
session description, the CIO, the object meta-data, or the ALC/LCT
control parameters), that are sent either in-band or out-of-band,
or</t>
<t>against some associated building blocks (e.g., the congestion
control component).</t>
</list></t>
<t>In the following sections we provide more details on these possible
attacks and sketch some possible counter-measures.</t>
</section>
<section anchor="attacks_against_data"
title="Attacks Against the Data Flow">
<!-- ==================================== -->
<t>Let us consider attacks against the data flow first. At least, the
following types of attacks exist: <list style="symbols">
<t>attacks that are meant to give access to a confidential object
(e.g., in case of a non-free content) and</t>
<t>attacks that try to corrupt the object being transmitted (e.g.,
to inject malicious code within an object, or to prevent a
receiver from using an object, which is a kind of Denial of
Service (DoS)).</t>
</list></t>
<section anchor="access_to_confidential_obj"
title="Access to Confidential Objects">
<!-- ==================================== -->
<t>Access control to the object being transmitted is typically
provided by means of encryption. This encryption can be done over
the whole object (e.g., by the content provider, before submitting
the object to FCAST), or be done on a packet per packet basis (e.g.,
when IPSec/ESP is used <xref target="RFC4303"></xref>). If
confidentiality is a concern, it is RECOMMENDED that one of these
solutions be used.</t>
</section>
<section anchor="obj_corruption" title="Object Corruption">
<!-- ==================================== -->
<t>Protection against corruptions (e.g., in case of forged packets)
is achieved by means of a content integrity verification/sender
authentication scheme. This service can be provided at the object
level, but in that case a receiver has no way to identify which
symbol(s) is(are) corrupted if the object is detected as corrupted.
This service can also be provided at the packet level. In this case,
after removing all corrupted packets, the file may be in some cases
recovered. Several techniques can provide this content
integrity/sender authentication service: <list style="symbols">
<t>at the object level, the object can be digitally signed (with
public key cryptography), for instance by using
RSASSA-PKCS1-v1_5 <xref target="RFC3447"></xref>. This signature
enables a receiver to check the object integrity, once this
latter has been fully decoded. Even if digital signatures are
computationally expensive, this calculation occurs only once per
object, which is usually acceptable;</t>
<t>at the packet level, each packet can be digitally signed. A
major limitation is the high computational and transmission
overheads that this solution requires (unless perhaps if
Elliptic Curve Cryptography (ECC) is used). To avoid this
problem, the signature may span a set of packets (instead of a
single one) in order to amortize the signature calculation. But
if a single packets is missing, the integrity of the whole set
cannot be checked;</t>
<t>at the packet level, a Group Message Authentication Code
(MAC) <xref target="RFC2104"></xref> scheme can be used, for
instance by using HMAC-SHA-1 with a secret key shared by all the
group members, senders and receivers. This technique creates a
cryptographically secured digest of a packet that is sent along
with the packet. The Group MAC scheme does not create
prohibitive processing load nor transmission overhead, but it
has a major limitation: it only provides a group
authentication/integrity service since all group members share
the same secret group key, which means that each member can send
a forged packet. It is therefore restricted to situations where
group members are fully trusted (or in association with another
technique as a pre-check);</t>
<t>at the packet level, Timed Efficient Stream Loss-Tolerant
Authentication (TESLA) <xref target="RFC4082"></xref> is an
attractive solution that is robust to losses, provides a true
authentication/integrity service, and does not create any
prohibitive processing load or transmission overhead. Yet
checking a packet requires a small delay (a second or more)
after its reception;</t>
<t>at the packet level, IPSec/AH <xref target="RFC4302"></xref>
(possibly associated to IPSec/ ESP) can be used to protect all
the packets being exchanged in a session.</t>
</list></t>
<t>Techniques relying on public key cryptography (digital signatures
and TESLA during the bootstrap process, when used) require that
public keys be securely associated to the entities. This can be
achieved by a Public Key Infrastructure (PKI), or by a PGP Web of
Trust, or by pre-distributing securely the public keys of each group
member.</t>
<t>Techniques relying on symmetric key cryptography (Group MAC)
require that a secret key be shared by all group members. This can
be achieved by means of a group key management protocol, or simply
by pre-distributing securely the secret key (but this manual
solution has many limitations).</t>
<t>It is up to the developer and deployer, who know the security
requirements and features of the target application area, to define
which solution is the most appropriate. In any case, whenever there
is any concern of the threat of file corruption, it is RECOMMENDED
that at least one of these techniques be used.</t>
</section>
</section>
<section anchor="attack_against_ctrl_param"
title="Attacks Against the Session Control Parameters and Associated Building Blocks">
<!-- ==================================== -->
<t>Let us now consider attacks against the session control parameters
and the associated building blocks. The attacker has at least the
following opportunities to launch an attack: <list style="symbols">
<t>the attack can target the session description,</t>
<t>the attack can target the FCAST CIO,</t>
<t>the attack can target the meta-data of an object,</t>
<t>the attack can target the ALC/LCT parameters, carried within
the LCT header or</t>
<t>the attack can target the FCAST associated building blocks.</t>
</list></t>
<t>The latter one is particularly true with the multiple rate
congestion control protocol which may be required.</t>
<t>The consequences of these attacks are potentially serious, since
they can compromise the behavior of content delivery system or even
compromise the network itself.</t>
<section anchor="attack_against_sdp"
title="Attacks Against the Session Description">
<!-- ==================================== -->
<t>An FCAST receiver may potentially obtain an incorrect Session
Description for the session. The consequence of this is that
legitimate receivers with the wrong Session Description are unable
to correctly receive the session content, or that receivers
inadvertently try to receive at a much higher rate than they are
capable of, thereby possibly disrupting other traffic in the
network.</t>
<t>To avoid these problems, it is RECOMMENDED that measures be taken
to prevent receivers from accepting incorrect Session Descriptions.
One such measure is the sender authentication to ensure that
receivers only accept legitimate Session Descriptions from
authorized senders. How these measures are archived is outside the
scope of this document since this session description is usually
carried out-of-band.</t>
</section>
<section anchor="attack_against_cio"
title="Attacks Against the FCAST CIO">
<!-- ==================================== -->
<t>Corrupting the FCAST CIO is one way to create a Denial of Service
attack. For example, the attacker can set the "Complete" flag to
make the receivers believe that no further modification will be done.
</t>
<t>It is therefore RECOMMENDED that measures be taken to guarantee
the integrity and to check the sender's identity of the CIO. To that
purpose, one of the counter-measures mentioned above (<xref
target="obj_corruption"></xref>) SHOULD be used. These measures will
either be applied on a packet level, or globally over the whole CIO
object. When there is no packet level integrity verification scheme,
it is RECOMMENDED to digitally sign the CIO.</t>
</section>
<section anchor="attack_against_meta_data"
title="Attacks Against the Object Meta-Data">
<!-- ==================================== -->
<t>Corrupting the object meta-data is another way to create a Denial
of Service attack. For example, the attacker changes the MD5 sum
associated to a file. This possibly leads a receiver to reject the
files received, no matter whether the files have been correctly
received or not. When the meta-data are appended to the object,
corrupting the meta-data means that the compound object will be
corrupted.</t>
<t>It is therefore RECOMMENDED that measures be taken to guarantee
the integrity and to check the sender's identity of the compound
object. To that purpose, one of the counter-measures mentioned above
(<xref target="obj_corruption"></xref>) SHOULD be used. These
measures will either be applied on a packet level, or globally over
the whole compound object. When there is no packet level integrity
verification scheme, it is RECOMMENDED to digitally sign the
compound object.</t>
<!-- XXX: how can we digitally sign a compound object? -->
</section>
<section anchor="attack_against_alc"
title="Attacks Against the ALC/LCT Parameters">
<!-- ==================================== -->
<t>By corrupting the ALC/LCT header (or header extensions) one can
execute attacks on the underlying ALC/LCT implementation. For
example, sending forged ALC packets with the Close Session flag (A)
set one can lead the receiver to prematurely close the session.
Similarly, sending forged ALC packets with the Close Object flag (B)
set one can lead the receiver to prematurely give up the reception
of an object.</t>
<t>It is therefore RECOMMENDED that measures be taken to guarantee
the integrity and to check the sender's identity of each ALC packet
received. To that purpose, one of the counter-measures mentioned
above (<xref target="obj_corruption"></xref>) SHOULD be used.</t>
</section>
<section anchor="attack_against_bb"
title="Attacks Against the Associated Building Blocks">
<!-- ==================================== -->
<t>Let us first focus on the congestion control building block that
may be used in the ALC session. A receiver with an incorrect or
corrupted implementation of the multiple rate congestion control
building block may affect the health of the network in the path
between the sender and the receiver. That may also affect the
reception rates of other receivers who joined the session.</t>
<t>When congestion control building block is applied with FCAST, it
is therefore RECOMMENDED that receivers be required to identify
themselves as legitimate before they receive the Session Description
needed to join the session. How receivers identify themselves as
legitimate is outside the scope of this document. If authenticating
a receiver does not prevent this latter to launch an attack, it will
enable the network operator to identify him and to take
counter-measures.</t>
<t>When congestion control building block is applied with FCAST/ALC,
it is also RECOMMENDED that a packet level authentication scheme be
used, as explained in <xref target="obj_corruption"></xref>. Some of
them, like TESLA, only provide a delayed authentication service,
whereas congestion control requires a rapid reaction. It is
therefore RECOMMENDED [2] that a receiver using TESLA quickly
reduces its subscription level when the receiver believes that a
congestion did occur, even if the packet has not yet been
authenticated. Therefore TESLA will not prevent DoS attacks where an
attacker makes the receiver believe that a congestion occurred. This
is an issue for the receiver, but this will not compromise the
network since no congestion actually occurred. Other authentication
methods that do not feature this delayed authentication could be
preferred, or a group MAC scheme could be used in parallel to TESLA
to reduce the probability of this attack.</t>
</section>
</section>
<section title="Other Security Considerations">
<!-- ==================================== -->
<t>Lastly, we note that the security considerations that apply to, and
are described in, ALC [2], LCT [3] and FEC [4] also apply to FCAST as
FCAST builds on those specifications. In addition, any security
considerations that apply to any congestion control building block
used in conjunction with FCAST also applies to FCAST.</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<!-- ==================================== -->
<t>This document requires a IANA registration for the following
attributes:</t>
<t>Object meta-data format (MDFmt): All implementations MUST support
format 0 (default).</t>
<texttable>
<preamble></preamble>
<ttcol align="center">format name</ttcol>
<ttcol align="center">Value</ttcol>
<c>as per HTTP/1.1 metainformation format</c>
<c>0 (default)</c>
</texttable>
<t>Object Meta-Data Encoding (MDENC): All implementations MUST support
value 0 (plain-text, default) and value 1 (gzip).</t>
<texttable>
<preamble></preamble>
<ttcol align="center">Name</ttcol>
<ttcol align="center">Value</ttcol>
<c>plain text</c>
<c>0 (default)</c>
<c>gzip</c>
<c>1</c>
</texttable>
</section>
<section title="Acknowledgments">
<!-- ==================================== -->
<t> The authors are grateful to the authors of <xref target="ALC_00"></xref> for specifying
the first version of FCAST/ALC.
The authors are also grateful to Gorry Fairhurst for his valuable comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- ==================================== -->
<?rfc include='reference.RFC.2119'?>
<reference anchor="RMT-PI-ALC">
<front>
<title>Asynchronous Layered Coding (ALC) Protocol
Instantiation</title>
<author initials="M." surname="Luby">
<organization></organization>
</author>
<author initials="M." surname="Watson">
<organization></organization>
</author>
<author initials="L." surname="Vicisano">
<organization></organization>
</author>
<date month="November" year="2007" />
</front>
<seriesInfo name="Work in" value="Progress" />
</reference>
<reference anchor="RMT-BB-LCT">
<front>
<title>Layered Coding Transport (LCT) Building Block</title>
<author initials="M." surname="Luby">
<organization></organization>
</author>
<author initials="M." surname="Watson">
<organization></organization>
</author>
<author initials="L." surname="Vicisano">
<organization></organization>
</author>
<date month="July" year="2008" />
</front>
<seriesInfo name="Work in" value="Progress" />
</reference>
<reference anchor="RMT-PI-NORM">
<front>
<title>Negative-acknowledgment (NACK)-Oriented Reliable Multicast
(NORM) Protocol</title>
<author initials="B." surname="Adamson">
<organization></organization>
</author>
<author initials="C." surname="Bormann">
<organization></organization>
</author>
<author initials="M." surname="Handley">
<organization></organization>
</author>
<author initials="J." surname="Macker">
<organization></organization>
</author>
<date month="May" year="2008" />
</front>
<seriesInfo name="Work in" value="Progress" />
</reference>
<reference anchor="RMT-FLUTE">
<front>
<title>FLUTE - File Delivery over Unidirectional Transport</title>
<author initials="T." surname="Paila">
<organization></organization>
</author>
<author initials="R." surname="Walsh">
<organization></organization>
</author>
<author initials="M." surname="Luby">
<organization></organization>
</author>
<author initials="R." surname="Lehtonen">
<organization></organization>
</author>
<author initials="V." surname="Roca">
<organization></organization>
</author>
<date month="October" year="2007" />
</front>
<seriesInfo name="Work in" value="Progress" />
</reference>
</references>
<references title="Informative References">
<!-- ==================================== -->
<reference anchor="ALC_00">
<front>
<title>Asynchronous Layered Coding: a Scalable Reliable Multicast
Protocol</title>
<author initials="M." surname="Luby">
<organization></organization>
</author>
<author initials="G." surname="Gemmell">
<organization></organization>
</author>
<author initials="L." surname="Vicisano">
<organization></organization>
</author>
<author initials="J." surname="Crowcroft">
<organization></organization>
</author>
<author initials="B." surname="Lueckenhoff">
<organization></organization>
</author>
<date month="March" year="2000" />
</front>
<seriesInfo name="" value="draft-ietf-rmt-pi-alc-00.txt" />
</reference>
<?rfc include='reference.RFC.1952'?>
<?rfc include='reference.RFC.2068'?>
<?rfc include='reference.RFC.2104'?>
<?rfc include='reference.RFC.3447'?>
<?rfc include='reference.RFC.4082'?>
<?rfc include='reference.RFC.4302'?>
<?rfc include='reference.RFC.4303'?>
</references>
<section title="FCAST Examples" anchor="fcast_exple">
<!-- ==================================== -->
<section title="Basic Examples">
<!-- ==================================== -->
<figure anchor="expl_object" title="Compound Object Example.">
<artwork align="center"><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |1|0| 0 | 0 | 39 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. meta-data ASCII null terminated string (33 bytes) .
. .
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Object data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t><xref target="expl_object"></xref> shows a regular compound object
where the meta-data ASCII string, in HTTP/1.1 meta-information format
(MDFmt=0) contains:</t>
<figure>
<artwork align="left"><![CDATA[
Content-Location: example.txt <CR-LF>
]]></artwork>
</figure>
<t>This string is 33 bytes long, including the NULL-termination
character. There is no gzip encoding of the meta-data (MDEnc=0) and there is
no Content-Length information either since this length can easily be
calculated by the receiver as the FEC OTI transfer length minus the
header length. Finally, the checksum encompasses the whole Compound
Object (G=1).</t>
<figure anchor="expl_no_meta-data"
title="Compound Object Example with no Meta-Data.">
<artwork align="center"><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |1|0| 0 | 0 | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Object data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t><xref target="expl_no_meta-data"></xref> shows a compound object
without any meta-data.
The fact there is no meta-data is indicated by the value 6 of the
Header Length field.</t>
<t><xref target="expl_cio"></xref> shows an example CIO object, in the
case of a static FCAST session, i.e., a session where the set of objects
is set once and for all.</t>
<figure align="center" anchor="expl_cio"
title="Example of CIO, in case of a static session.">
<artwork align="center"><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |1| 0 | 0 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Object List string .
. .
. +-+-+-+-+-+-+-+-+
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The object list contains the following string:</t>
<figure>
<artwork align="left"><![CDATA[
1,2,3,100-104,200-203,299
]]></artwork>
</figure>
<t>There are therefore a total of 3+5+4+1 = 13 objects in the carousel
instance, and therefore in the FCAST session. There is no meta-data
associated to this CIO. The session being static the sender did not feel
the necessity to carry a Carousel Instance ID meta-data.</t>
</section>
<section title="FCAST/NORM with NORM_INFO Examples">
<!-- ==================================== -->
<t>In case of FCAST/NORM, the meta-data (or a subset of it) can be
carried as part of a NORM_INFO message.
In the following example we assume that the whole meta-data is carried
in such a message for a certain object.
</t>
<t>
The NORM_INFO message is the following...
TODO
</t>
<t>
Note that this message contains the EXT_FTI header extension to
carry the FEC OTI. Two alternatives would have been to either
include FEC OTI directly in the meta-data part of the NORM_INFO
message, or to include an EXT_FTI header extension to all
NORM_DATA packets (or a subset of them).
</t>
<t>
The FCAST compound object does not contain any meta-data and is formatted
as in <xref target="expl_no_meta-data"></xref>.
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:59:16 |