One document matched: draft-ietf-rmt-flute-revised-14.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt'?>
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd" [
<!ENTITY rfc2357 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2357.xml">
<!ENTITY rfc3926 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3926.xml">
<!ENTITY rfc3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY rfc5052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5052.xml">
<!ENTITY rfc5445 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5445.xml">
<!ENTITY rfc5651 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5651.xml">
<!ENTITY rfc5751 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5751.xml">
<!ENTITY rfc5775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5775.xml">
<!ENTITY rfc5776 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5776.xml">
<!ENTITY rfc5905 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5905.xml">
]>
<?rfc toc='yes'?>
<?rfc compact='yes'?>
<?rfc symrefs='yes'?>
<?rfc subcompact='no'?>
<rfc category="std" docName="draft-ietf-rmt-flute-revised-14"
ipr="pre5378Trust200902" obsoletes="3926">
<!--<?rfc strict="yes" ?>-->
<front>
<title abbrev="FLUTE">FLUTE - File Delivery over Unidirectional
Transport</title>
<author fullname="Toni Paila" initials="T." surname="Paila">
<organization>Nokia</organization>
<address>
<postal>
<street>Itamerenkatu 11-13</street>
<city>Helsinki</city>
<code>00180</code>
<country>Finland</country>
</postal>
<email>toni.paila@nokia.com</email>
</address>
</author>
<author fullname="Rod Walsh" initials="R." surname="Walsh">
<organization>Tampere University of Technology</organization>
<address>
<postal>
<street>P.O. Box 553 (Korkeakoulunkatu 1)</street>
<city>Tampere</city>
<code>FI-33101</code>
<country>Finland</country>
</postal>
<email>roderick.walsh@tut.fi</email>
</address>
</author>
<author fullname="Michael Luby" initials="M." surname="Luby">
<organization>Qualcomm, Inc.</organization>
<address>
<postal>
<street>3165 Kifer Rd.</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>USA</country>
</postal>
<email>luby@qualcomm.com</email>
</address>
</author>
<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>
</address>
</author>
<author fullname="Rami Lehtonen" initials="R." surname="Lehtonen">
<organization>TeliaSonera</organization>
<address>
<postal>
<street>Hatanpaan valtatie 18</street>
<city>Tampere</city>
<code>FIN-33100</code>
<country>Finland</country>
</postal>
<email>rami.lehtonen@teliasonera.com</email>
</address>
</author>
<date day="12" month="March" year="2012" />
<area>Transport</area>
<workgroup>Reliable Multicast Transport (RMT)</workgroup>
<keyword>File</keyword>
<keyword>Delivery</keyword>
<keyword>Multicast</keyword>
<keyword>Unidirectional</keyword>
<abstract>
<t>This document defines FLUTE, a protocol for the unidirectional
delivery of files over the Internet, which is particularly suited to
multicast networks. The specification builds on Asynchronous Layered
Coding, the base protocol designed for massively scalable multicast
distribution. This document obsoletes RFC3926.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>This document defines FLUTE version 2, a protocol for unidirectional
delivery of files over the Internet. This specification is not
backwards compatible with the previous experimental version defined in
<xref target="RFC3926"></xref> (see <xref target="change-log"/> for details).
The specification builds on Asynchronous Layered Coding (ALC), version 1
<xref target="RFC5775"></xref>, the base protocol designed for
massively scalable multicast distribution. ALC defines transport of
arbitrary binary objects. For file delivery applications mere transport
of objects is not enough, however. The end systems need to know what
the objects actually represent. This document specifies a technique
called FLUTE - a mechanism for signaling and mapping the properties of
files to concepts of ALC in a way that allows receivers to assign those
parameters for received objects. Consequently, throughout this document
the term 'file' relates to an 'object' as discussed in ALC. Although
this specification frequently makes use of multicast addressing as an
example, the techniques are similarly applicable for use with unicast
addressing.</t>
<t>This document defines a specific transport application of ALC, adding
the following specifications: <list style="hanging">
<t hangText="-">Definition of a file delivery session built on top
of ALC, including transport details and timing constraints.</t>
<t hangText="-">In-band signaling of the transport parameters of the
ALC session.</t>
<t hangText="-">In-band signaling of the properties of delivered
files.</t>
<t hangText="-">Details associated with the multiplexing of multiple
files within a session.</t>
</list></t>
<t>This specification is structured as follows. Section 3 begins by
defining the concept of the file delivery session. Following that it
introduces the File Delivery Table that forms the core part of this
specification. Further, it discusses multiplexing issues of transmission
objects within a file delivery session. Section 4 describes the use of
congestion control and channels with FLUTE. Section 5 defines how the
Forward Error Correction (FEC) Object Transmission Information is to be
delivered within a file delivery session. Section 6 defines the required
parameters for describing file delivery sessions in a general case.
Section 7 outlines security considerations regarding file delivery with
FLUTE. Last, there are two informative appendices. Appendix A
describes an envisioned receiver operation for the receiver of the file
delivery session. Readers who want to see a simple example of FLUTE in
operation should refer to Appendix A right away. Appendix B gives
an example of a File Delivery Table.</t>
<t>This specification contains part of the definitions necessary to
fully specify a Reliable Multicast Transport protocol in accordance with
<xref target="RFC2357"/>.</t>
<t>This document obsoletes <xref target="RFC3926"/> which contained a previous version of
this specification and was published in the "Experimental" category.
This Proposed Standard specification is thus based on <xref target="RFC3926"/> updated
according to accumulated experience and growing protocol maturity since
the publication of <xref target="RFC3926"/>. Said experience applies both to this
specification itself and to congestion control strategies related to the
use of this specification.</t>
<t>The differences between <xref target="RFC3926"/> and this document are listed in <xref
target="change-log"></xref>.</t>
<t>This document updates ALC <xref target="RFC5775"/> and Layered
Coding Transport (LCT) <xref target="RFC5651"/>
in the sense it defines two new header extensions, EXT_FDT and EXT_CENC.</t>
<section anchor="applicability-statement"
title="Applicability Statement">
<section anchor="target-app-space"
title="The Target Application Space">
<t>FLUTE is applicable to the delivery of large and small files to
many hosts, using delivery sessions of several seconds or more. For
instance, FLUTE could be used for the delivery of large software
updates to many hosts simultaneously. It could also be used for
continuous, but segmented, data such as time-lined text for
subtitling - potentially leveraging its layering inheritance from
ALC and LCT to scale the richness of the session to the congestion
status of the network. It is also suitable for the basic transport
of metadata, for example SDP <xref target="RFC4566"></xref> files
which enable user applications to access multimedia sessions.</t>
</section>
<section anchor="target-scale" title="The Target Scale">
<t>Massive scalability is a primary design goal for FLUTE. IP
multicast is inherently massively scalable, but the best effort
service that it provides does not provide session management
functionality, congestion control or reliability. FLUTE provides all
of this using ALC and IP multicast without sacrificing any of the
inherent scalability of IP multicast.</t>
</section>
<section anchor="int-environ" title="Intended Environments">
<t>All of the environmental requirements and considerations that
apply to the RMT Building Blocks used by FLUTE shall also apply to
FLUTE. These are the ALC protocol instantiation <xref
target="RFC5775"></xref>, the Layered Coding Transport (LCT)
Building Block <xref target="RFC5651"/> and the FEC Building
Block <xref target="RFC5052"></xref>.</t>
<t>FLUTE can be used with both multicast and unicast delivery, but
it's primary application is for unidirectional multicast file
delivery. FLUTE requires connectivity between a sender and receivers
but does not require connectivity from receivers to a sender.
Because of its low expectations, FLUTE
works with most types of networks, including LANs, WANs,
Intranets, the Internet, asymmetric networks, wireless networks, and
satellite networks.</t>
<t>FLUTE is compatible with both IPv4 or IPv6 as no part of the
packet is IP version specific. FLUTE works with both multicast
models: Any-Source Multicast (ASM) <xref target="RFC1112"></xref>
and the Source-Specific Multicast (SSM) <xref
target="PAPER.SSM"></xref>.</t>
<t>FLUTE is applicable for both Internet use, with a suitable
congestion control building block, and provisioned/controlled
systems, such as delivery over wireless broadcast radio systems.</t>
</section>
<section anchor="weaknesses" title="Weaknesses">
<t>FLUTE congestion control protocols depend on the ability of a
receiver to change multicast subscriptions between multicast
groups supporting different rates and/or layered codings. If
the network does not support this, then the FLUTE congestion
control protocols may not be amenable to these networks.</t>
<t>FLUTE can also be used for point-to-point (unicast)
communications. At a minimum, implementations of ALC MUST support
the Wave and Equation Based Rate Control (WEBRC) <xref
target="RFC3738"></xref> multiple rate congestion control scheme
<xref target="RFC5775"></xref>. However, since WEBRC has been
designed for massively scalable multicast flows, it is not clear how
appropriate it is to the particular case of unicast flows. Using a
separate point-to-point congestion control scheme is another
alternative. How to do that is outside the scope of the present
document.</t>
<t>FLUTE provides reliability using the FEC building block. This
will reduce the error rate as seen by applications. However, FLUTE
does not provide a method for senders to verify the reception
success of receivers, and the specification of such a method is
outside the scope of this document.</t>
</section>
</section>
</section>
<section anchor="conventions" title="Conventions used in this Document">
<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"/>.</t>
<t>The terms "object" and "transmission object" are consistent with the
definitions in ALC <xref target="RFC5775"></xref> and LCT <xref
target="RFC5651"/>. The terms "file" and "source object" are
pseudonyms for "object".</t>
</section>
<section anchor="file-delivery" title="File delivery">
<t>Asynchronous Layered Coding <xref target="RFC5775"></xref> is
a protocol designed for delivery of arbitrary binary objects. It is
especially suitable for massively scalable, unidirectional, multicast
distribution. ALC provides the basic transport for FLUTE, and thus FLUTE
inherits the requirements of ALC.</t>
<t>This specification is designed for the delivery of files. The core of
this specification is to define how the properties of the files are
carried in-band together with the delivered files.</t>
<t>As an example, let us consider a 5200 byte file referred to by
"http://www.example.com/docs/file.txt". Using the example, the following
properties describe the properties that need to be conveyed by the file
delivery protocol.</t>
<t><list style="hanging">
<t hangText="*">Identifier of the file, expressed as a URI <xref target="RFC3986"/>.
The identifier MAY provide a location for the file. In the above
example: "http://www.example.com/docs/file.txt".</t>
<t hangText="*">File name (usually, this can be concluded from the
URI). In the above example: "file.txt".</t>
<t hangText="*">File type, expressed as Internet Media Types (often
referred to as "MIME Media Types"). In the above example: "text/plain".</t>
<t hangText="*">File size, expressed in octets. In the above
example: "5200". If the file is content encoded then this is the
file size before content encoding.</t>
<t hangText="*">Content encoding of the file, within transport. In
the above example, the file could be encoded using ZLIB <xref
target="RFC1950"></xref>. In this case the size of the transmission
object carrying the file would probably differ from the file size.
The transmission object size is delivered to receivers as part of
the FLUTE protocol.</t>
<t hangText="*">Security properties of the file such as digital
signatures, message digests, etc. For example, one could use S/MIME
<xref target="RFC5751"></xref> as the content encoding type for
files with this authentication wrapper, and one could use XML-DSIG
<xref target="RFC3275"></xref> to digitally sign the file.
XML-DSIG can also be used to provide tamper prevention
e.g., on the Content-Location field. Content encoding is applied to
file data before FEC protection.</t>
</list></t>
<t>For each unique file, FLUTE encodes the attributes listed above
and other attributes as children of an XML file element. A
table of XML file elements is transmitted as a special file
called a 'File Delivery Table' (FDT) which is further described
in the next subsection and in section 3.2</t>
<section anchor="file-delivery-session" title="File delivery session">
<t>ALC is a protocol instantiation of Layered Coding Transport
building block (LCT) <xref target="RFC5651"/>. Thus ALC inherits
the session concept of LCT. In this document we will use the concept
ALC/LCT session to collectively denote the interchangeable terms ALC
session and LCT session.</t>
<t>An ALC/LCT session consists of a set of logically grouped ALC/LCT
channels associated with a single sender sending ALC/LCT packets for
one or more objects. An ALC/LCT channel is defined by the combination
of a sender and an address associated with the channel by the
sender. A receiver joins a channel to start receiving the data packets
sent to the channel by the sender, and a receiver leaves a channel to
stop receiving data packets from the channel.</t>
<t>One of the fields carried in the ALC/LCT header is the Transport
Session Identifier (TSI), an integer carried in a field of size 16,
32, or 48 bits (note that the TSI may be carried by other means
in which case it is absent from the LCT header <xref target="RFC5651"/>).
The (source IP address, TSI) pair uniquely
identifies a session. Note that the TSI is scoped by the IP address,
so the same TSI may be used by several source IP addresses at once.
Thus, the receiver uses the (source IP address, TSI) pair from each
packet to uniquely identify the session sending each packet. When a
session carries multiple objects, the Transmission Object Identifier
(TOI) field within the ALC/LCT header names the object used to generate
each packet. Note that each object is associated with a unique TOI
within the scope of a session.</t>
<t>A FLUTE session consistent with this specification MUST use FLUTE
version 2 as specified in this document. Thus, all sessions consistent
with this specification MUST set the FLUTE version to 2. The FLUTE
version is carried within the EXT_FDT extension header (defined in
section 3.4.1) in the ALC/LCT layer. A FLUTE session consistent with
this specification MUST use ALC version 1 as specified in <xref target="RFC5775"/>, and
LCT version 1 as specified in <xref target="RFC5651"/>.</t>
<t>If multiple FLUTE sessions are sent to a channel then receivers MUST
determine the FLUTE protocol version, based on version fields and the
(source IP address, TSI) carried in the ALC/LCT header of the packet.
Note that when a receiver first begins receiving packets, it might not
know the FLUTE protocol version, as not every LCT packet carries the
EXT_FDT header (containing the FLUTE protocol version.) A new receiver
MAY keep an open binding in the LCT protocol layer between the TSI and
the FLUTE protocol version, until the EXT_FDT header arrives.
Alternately, a new receiver MAY discover a binding between TSI and
FLUTE protocol version via a session discovery protocol that is out of
scope in this document.</t>
<t>If the sender's IP address is not accessible to
receivers, then packets that can be received by receivers contain an
intermediate IP address. In this case the TSI is scoped by this
intermediate IP address of the sender for the duration of the session. As
an example, the sender may be behind a Network Address Translation
(NAT) device that temporarily assigns an IP address for the sender.
In this case the TSI is scoped by the intermediate IP address
assigned by the NAT. As another example, the sender may send its
original packets using IPv6, but some portions of the network may not
be IPv6 capable. Thus, there may be an IPv6 to IPv4 translator that
changes the IP address of the packets to a different IPv4 address. In
this case, receivers in the IPv4 portion of the network will receive
packets containing the IPv4 address, and thus the TSI for them is
scoped by the IPv4 address. How the IP address of the sender to be
used to scope the session by receivers is delivered to receivers,
whether it is the sender's IP address or an intermediate IP address, is
outside the scope of this document.</t>
<t>When FLUTE is used for file delivery over ALC the following rules
apply: <list style="hanging">
<t hangText="*">The ALC/LCT session is called a file delivery
session.</t>
<t hangText="*">The ALC/LCT concept of 'object' denotes either a
'file' or a 'File Delivery Table Instance' (section 3.2)</t>
<t hangText="*">The TOI field MUST be included in ALC packets
sent within a FLUTE session, with the exception that ALC packets
sent in a FLUTE session with the Close Session (A) flag set to 1
(signaling the end of the session) and that contain no payload
(carrying no information for any file or FDT) SHALL NOT carry the
TOI. See section 5.1 of <xref target="RFC5651"/>
for the LCT definition of the Close Session flag, and see section
4.2 of <xref target="RFC5775"></xref> for an
example of the use of a TOI within an ALC packet.</t>
<t hangText="*">The TOI value '0' is reserved for delivery of File
Delivery Table Instances. Each non expired File Delivery Table
Instance is uniquely identified by an FDT Instance ID
within the EXT_FDT header defined in section 3.4.1.</t>
<t hangText="*">Each file in a file delivery session MUST be
associated with a TOI (>0) in the scope of that session.</t>
<t hangText="*">Information carried in the headers and the payload
of a packet is scoped by the source IP address and the TSI.
Information particular to the object carried in the headers and
the payload of a packet is further scoped by the TOI for file
objects, and is further scoped by both the TOI and the FDT
Instance ID for FDT Instance objects.</t>
</list></t>
</section>
<section anchor="fdt" title="File Delivery Table">
<t>The File Delivery Table (FDT) provides a means to describe various
attributes associated with files that are to be delivered within the
file delivery session. The following lists are examples of such
attributes, and are not intended to be mutually exclusive nor
exhaustive.</t>
<t>Attributes related to the delivery of file: <list style="hanging">
<t hangText="-">TOI value that represents the file</t>
<t hangText="-">FEC Object Transmission Information (including the
FEC Encoding ID and, if relevant, the FEC Instance ID)</t>
<t hangText="-">Size of the transmission object carrying the
file</t>
<t hangText="-">Aggregate rate of sending packets to all
channels</t>
</list></t>
<t>Attributes related to the file itself: <list style="hanging">
<t hangText="-">Name, Identification and Location of file
(specified by the URI)</t>
<t hangText="-">MIME media type of file</t>
<t hangText="-">Size of file</t>
<t hangText="-">Encoding of file</t>
<t hangText="-">Message digest of file</t>
</list></t>
<t>Some of these attributes MUST be included in the file description
entry for a file, others are optional, as defined in section
3.4.2.</t>
<t>Logically, the FDT is a set of file description entries for files
to be delivered in the session. Each file description entry MUST
include the TOI for the file that it describes and the URI identifying
the file. The TOI carried in each file description entry is how
FLUTE names the ALC/LCT data packets used for delivery of the file.
Each file description entry may also contain one or more descriptors
that map the above-mentioned attributes to the file.</t>
<t>Each file delivery session MUST have an FDT that is local to the
given session. The FDT MUST provide a file description entry mapped to
a TOI for each file appearing within the session. An object that is
delivered within the ALC session, but not described in the FDT, other
than the FDT itself, is not considered a 'file' belonging to the file
delivery session. This object received with an unmapped TOI
(Non-zero TOI that is not resolved by the FDT) SHOULD in general be
ignored by a FLUTE receiver. The details of how to do that is out of
scope of this specification.</t>
<t>Note that a client that joins an active file delivery session MAY receive
data packets for a TOI > 0 before receiving any FDT Instance
(see <xref target="fdt-dynamics"/> for recommendations on how to limit
the probability this occurs). Even if the TOI is not mapped to any file
description entry, this is hopefully a transient situation.
When this happens, system performance might be improved by caching such
packets within a reasonable time window and storage size. Such optimizations
are use-case and implementation specific and further details are beyond
the scope of this document.
</t>
<t>Within the file delivery session the FDT is delivered as FDT
Instances. An FDT Instance contains one or more file description
entries of the FDT. Any FDT Instance can be equal to, a subset of, a
superset of, overlap with or complement any other FDT Instance. A
certain FDT Instance may be repeated multiple times during a session,
even after subsequent FDT Instances (with higher FDT Instance ID
numbers) have been transmitted. Each FDT Instance contains at least a
single file description entry and at most the exhaustive set of file
description entries of the files being delivered in the file delivery
session.</t>
<t>A receiver of the file delivery session keeps an FDT database for
received file description entries. The receiver maintains the
database, for example, upon reception of FDT Instances. Thus, at any
given time the contents of the FDT database represent the receiver's
current view of the FDT of the file delivery session. Since each
receiver behaves independently of other receivers, it SHOULD NOT be
assumed that the contents of the FDT database are the same for all the
receivers of a given file delivery session.</t>
<t>Since the FDT database is an abstract concept, the structure and the
maintenance of the FDT database are left to individual implementations
and are thus out of scope of this specification.</t>
</section>
<section anchor="fdt-dynamics"
title="Dynamics of FDT Instances within file delivery session">
<t>The following rules define the dynamics of the FDT Instances within
a file delivery session: <list style="hanging">
<t hangText="*">For every file delivered within a file delivery
session there MUST be a file description entry included in at
least one FDT Instance sent within the session. A file description
entry contains at a minimum the mapping between the TOI and the
URI.</t>
<t hangText="*">An FDT Instance MAY appear in any part of the file
delivery session and packets for an FDT Instance MAY be
interleaved with packets for other files or other FDT Instances
within a session.</t>
<t hangText="*">The TOI value of '0' MUST be reserved for delivery
of FDT Instances. The use of other TOI values (i.e., an integer > 0)
for FDT Instances is outside the scope of this specification.</t>
<t hangText="*">The FDT Instance is identified by the use of a new
fixed length LCT Header Extension EXT_FDT (defined later in this
section.) Each non expired FDT Instance is uniquely identified
within the file delivery session by its FDT Instance ID, carried
by the EXT_FDT Header Extension. Any ALC/LCT packet carrying an FDT
Instance MUST include EXT_FDT.</t>
<t hangText="*">It is RECOMMENDED that an FDT Instance that
contains the file description entry for a file is sent at least
once before sending the described file within a file delivery
session. This recommendation is intended to minimize the amount
of file data which may be received by receivers in advance of the
FDT Instance containing the entry for a file (such data must
either be speculatively buffered or discarded). Note that this
possibility cannot be completely eliminated since the first
transmission of FDT data might be lost.</t>
<t hangText="*">Within a file delivery session, any TOI > 0 MAY
be described more than once. An example: previous FDT Instance 0
describes TOI of value '3'. Now, subsequent FDT Instances can
either keep TOI '3' unmodified on the table, not include it, or
augment the description. However, subsequent FDT Instances MUST
NOT change the parameters already described for a specific
TOI.</t>
<t hangText="*">An FDT Instance is valid until its expiration
time. The expiration time is expressed within the FDT Instance
payload as an UTF-8 decimal representation of a 32 bit unsigned
integer. The value of this integer represents the 32 most
significant bits of a 64 bit Network Time Protocol (NTP) <xref
target="RFC5905"></xref> time value. These 32 bits provide an
unsigned integer representing the time in seconds relative to 0
hours 1 January 1900 in case of the prime epoch (era 0) <xref
target="RFC5905"></xref>. The handling of time wraparound (to happen
in 2036) requires to consider the associated epoch. In any case,
both a sender and a receiver can determine to which (136 year) epoch
the FDT Instance expiration time value pertains to by choosing the
epoch for which the expiration time is closest in time to the
current time.</t>
<t>
Here is an example.
Let us imagine a new FLUTE session is started on February
7th, 2036, 0h, i.e., at NTP time 4,294,944,000, a few hours
before the end of epoch 0.
In order to define an FDT Instance valid for the next 48 hours,
The FLUTE sender sets an expiry time of 149,504.
This FDT Instance will expire exactly on February 9th, 2036, 0h.
A client that receives this FDT Instance on the 7th, 0h, just
after it has been sent, immediately understands this value
corresponds to epoch 1.
A client that joins the session on February 8th, 0h, i.e., at
NTP time 63,104, epoch 1, immediately understands that the
149,504 NTP timestamp corresponds to epoch 1.
</t>
<t hangText="*">The space of FDT Instance IDs is limited by the
associated field size (i.e., 20 bits) in the EXT_FDT header
extension (<xref target="ext-fdt"/>). Therefore
senders should take care to always have a large enough supply of
available FDT Instance IDs when specifying FDT expiration times.</t>
<t hangText="*">The receiver MUST NOT use a received FDT
Instance to interpret packets received beyond the expiration time
of the FDT Instance.</t>
<t hangText="*">A sender MUST use an expiration time in the future
upon creation of an FDT Instance relative to its Sender Current
Time (SCT).</t>
<t hangText="*">Any FEC Encoding ID MAY be used for the sending of
FDT Instances. The default is to use the Compact No-code FEC
Encoding ID 0 <xref target="RFC5445"></xref>
for the sending of FDT Instances. (Note that since FEC Encoding
ID 0 is the default for FLUTE, this
implies that Source Block Number and Encoding Symbol ID lengths
both default to 16 bits each.)</t>
<t hangText="*">If the receiver does not support the FEC scheme
indicated by the FEC Encoding ID, the receiver MUST NOT decode
the associated FDT.</t>
<t hangText="*">It is RECOMMENDED that the mechanisms used for
file attribute delivery SHOULD achieve a delivery probability
that is higher than the file recovery probability and the file
attributes SHOULD be delivered at this higher priority before
the delivery of the associated files begins.</t>
</list></t>
<t>Generally, a receiver needs to receive an FDT Instance describing a
file before it is able to recover the file itself. In this sense FDT
Instances are of higher priority than files. Additionally, a FLUTE
sender SHOULD assume receivers will not receive all packets pertaining
to FDT Instances. The way FDT Instances are transmitted has a large
impact on satisfying the recommendation above. When there is a single
file transmitted in the session, one way to satisfy the recommendation
above is to repeatedly transmit on a regular enough basis FDT Instances
describing the file while the file is being transmitted. If an FDT
Instance is longer than one packet payload in length, it is RECOMMENDED
that an FEC code that provides protection against loss be used for
delivering this FDT Instance. When there are multiple files in a
session concurrently being transmitted to receivers, the way the FDT
Instances are structured and transmitted also has a large impact. As
an example, a way to satisfy the recommendation above is to transmit an
FDT Instance that describes all files currently being transmitted, and
to transmit this FDT Instance reliably, using the same techniques as
explained for the case when there is a single file transmitted in a
session. If instead the concurrently transmitted files are described in
separate FDT Instances, another way to satisfy this recommendation is
to transmit all the relevant FDT Instances reliably, using the same
techniques as explained for the case when there is a single file
transmitted in a session.</t>
<t>In any case, how often the description of a file is sent in an FDT
Instance, how often an FDT Instance is sent, and how much FEC
protection is provided for an FDT Instance (if longer than one packet
payload) are dependent on the particular application and are outside
the scope of this document.</t>
<t>Sometimes the various attributes associated with files that are to
be delivered within the file delivery session are sent out-of-band
(rather than in-band, within one or several FDT Instances). The
details of how this is done are out of the scope of this document.
However, it is still RECOMMENDED that any out-of-band transmission be
managed in such a way that a receiver will be able to recover the
attributes associated with a file with as much or greater reliability
as the receiver is able to receive enough packets containing encoding
symbols to recover the file. For example, the probability of a
randomly chosen receiver being able to recover a given file can often
be estimated based on a statistical model of reception conditions, the
amount of data transmitted and the properties of any Forward Error
Correction in use. The recommendation above suggests that mechanisms
used for file attribute delivery should achieve higher a delivery
probability than the file recovery probability.</t>
</section>
<section anchor="fdt-structure"
title="Structure of FDT Instance packets">
<t>FDT Instances are carried in ALC packets with TOI = 0 and with an
additional REQUIRED LCT Header extension called the FDT Instance
Header. The FDT Instance Header (EXT_FDT) contains the FDT Instance ID
that uniquely identifies FDT Instances within a file delivery session.
The FDT Instance Header is placed in the same way as any other LCT
extension header. There MAY be other LCT extension headers in use.</t>
<t>The FDT Instance is encoded for transmission, like any other object,
using an FEC Scheme (which MAY be the Compact No-Code FEC Scheme) The
LCT extension headers are followed by the FEC Payload ID, and finally
the Encoding Symbols for the FDT Instance which contains one or more
file description entries. A FDT Instance MAY span several ALC packets -
the number of ALC packets is a function of the file attributes
associated with the FDT Instance. The FDT Instance Header is carried in
each ALC packet carrying the FDT Instance. The FDT Instance Header is
identical for all ALC/LCT packets for a particular FDT Instance.</t>
<t>The overall format of ALC/LCT packets carrying an FDT Instance is
depicted in the Figure 1 below. All integer fields are carried in
"big-endian" or "network order" format, that is, most significant byte
(octet) first. As defined in <xref target="RFC5775"></xref>,
all ALC/LCT packets are sent using UDP.</t>
<figure anchor="overall-flute-packet" title="Overall FDT Packet">
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Default LCT header (with TOI = 0) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCT header extensions (EXT_FDT, EXT_FTI, etc.) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FLUTE Payload: Encoding Symbol(s)
~ (for FDT Instance in a FDT packet) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<section anchor="ext-fdt" title="Format of FDT Instance Header">
<t>The FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI
specific LCT header extension <xref target="RFC5651"/>. The
Header Extension Type (HET) for the extension is 192. Its format is
defined below:</t>
<figure anchor="fig-ext-fdt">
<artwork><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 192 | V | FDT Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Version of FLUTE (V), 4 bits:</t>
<t>This document specifies FLUTE version 2. Hence in any ALC packet
that carries FDT Instance and that belongs to the file delivery
session as specified in this specification MUST set this field to
'2'.</t>
<t>FDT Instance ID, 20 bits:</t>
<t>For each file delivery session the numbering of FDT Instances
starts from '0' and is incremented by one for each subsequent FDT
Instance. After reaching the maximum value (2^20-1), the numbering
starts from the smallest FDT Instance value assigned to an expired
FDT Instance. When wraparound from a greater FDT Instance ID value
to a smaller FDT Instance ID value occurs, the smaller FDT Instance
ID value is considered logically higher than the greater FDT
Instance ID value. Senders MUST NOT re-use an FDT Instance ID
value that is already in use for a non-expired FDT Instance. Sender
behavior when all the FDT Instance IDs are used by non expired FEC
Instances is outside the scope of this specification and left to
individual implementations of FLUTE. Receipt of an FDT Instance that
reuses an FDT Instance ID value that is currently used by a non
expired FDT Instance SHOULD be considered as an error case. Receiver
behavior in this case (e.g. leave the session or ignore the new FDT
Instance) is outside the scope of this specification
and left to individual implementations of FLUTE. Receivers MUST be
ready to handle FDT Instance ID wraparound and situations where
missing FDT Instance IDs result in increments larger than one.</t>
</section>
<section anchor="fdt-syntax" title="Syntax of FDT Instance">
<t>The FDT Instance contains file description entries that provide
the mapping functionality described in 3.2 above.</t>
<t>The FDT Instance is an XML structure that has a single root
element "FDT-Instance". The "FDT-Instance" element MUST contain
"Expires" attribute, which tells the expiration time of the FDT
Instance. In addition, the "FDT-Instance" element MAY contain the
"Complete" attribute (boolean), which, when TRUE, signals that this
"FDT Instance" includes the set of "File" entries that exhausts both
the set of files delivered so far and also the set of files to be
delivered in the session. This implies that no new data will be
provided in future FDT Instances within this session (i.e., that
either FDT Instances with higher ID numbers will not be used or if
they are used, will only provide identical file parameters to those
already given in this and previous FDT Instances). The "Complete"
attribute is therefore used to provide a complete list of files in
an entire FLUTE session (a "complete FDT").</t>
<t>The "FDT-Instance" element MAY contain attributes that give
common parameters for all files of an FDT Instance. These attributes
MAY also be provided for individual files in the "File" element.
Where the same attribute appears in both the "FDT-Instance" and the
"File" elements, the value of the attribute provided in the "File"
element takes precedence.</t>
<t>For each file to be declared in the given FDT Instance there is a
single file description entry in the FDT Instance. Each entry is
represented by element "File" which is a child element of the FDT
Instance structure.</t>
<t>The attributes of "File" element in the XML structure represent
the attributes given to the file that is delivered in the file
delivery session. The value of the XML attribute name corresponds to
MIME field name and the XML attribute value corresponds to the value
of the MIME field body. Each "File" element MUST contain at least
two attributes "TOI" and "Content-Location". "TOI" MUST be assigned
a valid TOI value as described in section 3.3 above.
"Content-Location" MUST be assigned a valid URI as defined in <xref
target="RFC2616"></xref> which identifies the object to be
delivered, for example a URI with the "http" or "file" URI scheme.
The semantics for any two "File" elements declaring the same
"Content-Location" but differing "TOI" is that the element appearing
in the FDT Instance with the greater FDT Instance ID is considered
to declare newer instance (e.g., version) of the same "File".</t>
<t>In addition to mandatory attributes, the "FDT-Instance" element
and the "File" element MAY contain other attributes of which the
following are specifically pointed out.
<list style="hanging">
<t hangText="*">The attribute "Content-Type" SHOULD be included
and, when present, MUST be used for the purpose defined in <xref
target="RFC2616"></xref>.</t>
<t hangText="*">Where the length is described, the attribute
"Content-Length" MUST be used for the purpose as defined in
<xref target="RFC2616"></xref>. The transfer length is
defined to be the length of the object transported in octets. It
is often important to convey the transfer length to receivers,
because the source block structure needs to be known for the FEC
decoder to be applied to recover source blocks of the file, and
the transfer length is often needed to properly determine the
source block structure of the file. There generally will be a
difference between the length of the original file and the
transfer length if content encoding is applied to the file
before transport, and thus the "Content-Encoding" attribute is
used. If the file is not content encoded before transport (and
thus the "Content-Encoding" attribute is not used) then the
transfer length is the length of the original file, and in this
case the "Content-Length" is also the transfer length. However,
if the file is content encoded before transport (and thus the
"Content-Encoding" attribute is used), e.g., if compression is
applied before transport to reduce the number of octets that need
to be transferred, then the transfer length is generally
different than the length of the original file, and in this case
the attribute "Transfer-Length" MAY be used to carry the
transfer length.</t>
<t hangText="*">Whenever content encoding is applied the
attribute "Content-Encoding" MUST be included. Whenever the
attribute "Content-Encoding" is included it MUST be used as
described in <xref target="RFC2616"></xref>.</t>
<t hangText="*">Where the MD5 message digest is described, the
attribute "Content-MD5" MUST be used for the purpose as defined
in <xref target="RFC2616"/>.
Note that the goal is to provide a decoded object integrity
service in front of transmission and/or FLUTE/ALC processing
errors (the collision probability is in that case negligible).
It MUST NOT be regarded as a security mechanism
(see <xref target="sec-cons"/> to that purpose).</t>
<t hangText="*">The FEC Object Transmission Information
attributes as described in section 5.2.</t>
</list></t>
<t>The following specifies the XML Schema <xref
target="XML-Schema-Part-1"></xref><xref
target="XML-Schema-Part-2"></xref> for FDT Instance:</t>
<figure anchor="fig-fdt-instance">
<artwork><![CDATA[
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="urn:ietf:params:xml:ns:fdt"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:fdt"
elementFormDefault="qualified">
<xs:element name="FDT-Instance" type="FDT-InstanceType"/>
<xs:complexType name="FDT-InstanceType">
<xs:sequence>
<xs:element name="File" type="FileType" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="skip"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Expires"
type="xs:string"
use="required"/>
<xs:attribute name="Complete"
type="xs:boolean"
use="optional"/>
<xs:attribute name="Content-Type"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-Encoding"
type="xs:string"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Encoding-ID"
type="xs:unsignedByte"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Instance-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Scheme-Specific-Info"
type="xs:base64Binary"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
<xs:complexType name="FileType">
<xs:sequence>
<xs:any namespace="##other" processContents="skip"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Content-Location"
type="xs:anyURI"
use="required"/>
<xs:attribute name="TOI"
type="xs:positiveInteger"
use="required"/>
<xs:attribute name="Content-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="Transfer-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="Content-Type"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-Encoding"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-MD5"
type="xs:base64Binary"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Encoding-ID"
type="xs:unsignedByte"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Instance-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Scheme-Specific-Info"
type="xs:base64Binary"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
</xs:schema>
END
]]></artwork>
</figure>
<t>Any valid FDT Instance MUST use the above XML Schema. This way
FDT provides extensibility to support private attributes within the
file description entries. Those could be, for example, the
attributes related to the delivery of the file (timing, packet
transmission rate, etc.). Unsupported private attributes SHOULD be
silently ignored by a FLUTE receiver.</t>
<t>In case the basic FDT XML Schema is extended in terms of new
descriptors (attributes or elements), for descriptors applying to a
single file, those MUST be placed within the element "File". For
descriptors applying to all files described by the current FDT
Instance, those MUST be placed within the element "FDT-Instance". It
is RECOMMENDED that the new attributes applied in the FDT are in the
format of MIME fields and are either defined in the HTTP/1.1
specification <xref target="RFC2616"></xref>, or another well-known
specification, or in IANA registry <xref target="IANAmediatypes"/>.</t>
</section>
<section anchor="fdt-encoding"
title="Content Encoding of FDT Instance">
<t>The FDT Instance itself MAY be content encoded, for example
compressed. This specification defines FDT Instance Content Encoding
Header (EXT_CENC). EXT_CENC is a new fixed length LCT header
extension <xref target="RFC5651"/>. The Header Extension Type
(HET) for the extension is 193. If the FDT Instance is content
encoded, the EXT_CENC MUST be used to signal the content encoding
type. In that case, EXT_CENC header extension MUST be used in all
ALC packets carrying the same FDT Instance ID. Consequently, when
EXT_CENC header is used, it MUST be used together with a proper FDT
Instance Header (EXT_FDT). Within a file delivery session, FDT
Instances that are not content encoded and FDT Instances that are
content encoded MAY both appear. If content encoding is not used for
a given FDT Instance, the EXT_CENC MUST NOT be used in any packet
carrying the FDT Instance. The format of EXT_CENC is defined
below:</t>
<figure anchor="fig-ext-cenc">
<artwork><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 193 | CENC | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Content Encoding Algorithm (CENC), 8 bits:</t>
<t>This field signals the content encoding algorithm used in the FDT
Instance payload. This subsection reserves the Content Encoding
Algorithm values 0, 1, 2 and 3 for null, ZLIB <xref
target="RFC1950"></xref>, DEFLATE <xref
target="RFC1951"></xref> and GZIP <xref
target="RFC1952"></xref> respectively.</t>
<t>Reserved, 16 bits:</t>
<t>This field MUST be set to all '0'. This field MUST be ignored
on reception.</t>
</section>
</section>
<section anchor="mix-session"
title="Multiplexing of files within a file delivery session">
<t>The delivered files are carried as transmission objects (identified
with TOIs) in the file delivery session. All these objects, including
the FDT Instances, MAY be multiplexed in any order and in parallel
with each other within a session, i.e., packets for one file may be
interleaved with packets for other files or other FDT Instances within
a session.</t>
<t>Multiple FDT Instances MAY be delivered in a single session using
TOI = 0. In this case, it is RECOMMENDED that the sending of a
previous FDT Instance SHOULD end before the sending of the next FDT
Instance starts. However, due to unexpected network conditions,
packets for the FDT Instances MAY be interleaved. A receiver can
determine which FDT Instance a packet contains information about since
the FDT Instances are uniquely identified by their FDT Instance ID
carried in the EXT_FDT headers.</t>
</section>
</section>
<section anchor="channels-cc-timing"
title="Channels, congestion control and timing">
<t>ALC/LCT has a concept of channels and congestion control. There are
four scenarios in which FLUTE is envisioned to be applied.
<list style="hanging">
<t hangText="(a)">Use of a single channel and a single-rate congestion
control protocol.</t>
<t hangText="(b)">Use of multiple channels and a multiple-rate
congestion control protocol. In this case the FDT Instances MAY be
delivered on more than one channel.</t>
<t hangText="(c)">Use of a single channel without congestion control
supplied by ALC, but only when in a controlled network environment
where flow/congestion control is being provided by other means.</t>
<t hangText="(d)">Use of multiple channels without congestion control
supplied by ALC, but only when in a controlled network environment
where flow/congestion control is being provided by other means. In
this case the FDT Instances MAY be delivered on more than one
channel.</t>
</list></t>
<t>When using just one channel for a file delivery session, as in (a)
and (c), the notion of 'prior' and 'after' are intuitively defined for
the delivery of objects with respect to their delivery times.</t>
<t>However, if multiple channels are used, as in (b) and (d), it is not
straightforward to state that an object was delivered 'prior' to the
other. An object may begin to be delivered on one or more of those
channels before the delivery of a second object begins. However, the use
of multiple channels/layers may complete the delivery of the second
object before the first. This is not a problem when objects are
delivered sequentially using a single channel. Thus, if the application
of FLUTE has a mandatory or critical requirement that the first
transmission object must complete 'prior' to the second one, it is
RECOMMENDED that only a single channel is used for the file delivery
session.</t>
<t>Furthermore, if multiple channels are used then a receiver joined to
the session at a low reception rate will only be joined to the lower
layers of the session. Thus, since the reception of FDT Instances is of
higher priority than the reception of files (because the reception of
files depends on the reception of an FDT Instance describing it), the
following is RECOMMENDED: <list style="hanging">
<t hangText="1.">The layers to which packets for FDT Instances are
sent SHOULD NOT be biased towards those layers to which lower rate
receivers are not joined. For example, it is okay to put all the
packets for an FDT Instance into the lowest layer (if this layer
carries enough packets to deliver the FDT to higher rate receivers
in a reasonable amount of time), but it is not okay to put all the
packets for an FDT Instance into the higher layers that only high
rate receivers will receive.</t>
<t hangText="2.">If FDT Instances are generally longer than one
Encoding Symbol in length and some packets for FDT Instances are
sent to layers that lower rate receivers do not receive, an FEC
Encoding other than Compact No-code FEC Encoding ID 0 <xref
target="RFC5445"></xref> SHOULD be used to deliver FDT
Instances. This is because in this case, even when there is no
packet loss in the network, a lower rate receiver will not receive
all packets sent for an FDT Instance.</t>
</list></t>
</section>
<section anchor="deliv-fec-oti"
title="Delivering FEC Object Transmission Information">
<t>FLUTE inherits the use of FEC building block <xref
target="RFC5052"></xref> from ALC. When using FLUTE for file delivery
over ALC the FEC Object Transmission Information MUST be delivered
in-band within the file delivery session. There are two methods to
achieve this: the use of ALC specific LCT extension header EXT_FTI <xref
target="RFC5775"></xref> and the use of FDT. The latter method is
specified in this section. The use of EXT_FTI requires repetition of the
FEC Object Transmission Information to ensure reception (though not
necessarily in every packet) and thus may entail higher overhead than
the use of the FDT, but may also provide more timely delivery of the FEC
Object Transmission Information.</t>
<t>The receiver of file delivery session MUST support delivery of FEC
Object Transmission Information using the EXT_FTI for the FDT Instances
carried using TOI value 0. For the TOI values other than 0 the receiver
MUST support both methods: the use of EXT_FTI and the use of FDT.</t>
<t>The FEC Object Transmission Information that needs to be delivered to
receivers MUST be exactly the same whether it is delivered using EXT_FTI
or using FDT (or both). The FEC Object Transmission Information that
MUST be delivered to receivers is defined by the FEC Scheme. This
section describes the delivery using FDT.</t>
<t>The FEC Object Transmission Information regarding a given TOI may be
available from several sources. In this case, it is RECOMMENDED that the
receiver of the file delivery session prioritize the sources in the
following way (in the order of decreasing priority). <list
style="hanging">
<t hangText="1.">FEC Object Transmission Information that is
available in EXT_FTI.</t>
<t hangText="2.">FEC Object Transmission Information that is
available in the FDT.</t>
</list></t>
<t>The FDT delivers FEC Object Transmission Information for each file
using an appropriate attribute within the "FDT-Instance" or the "File"
element of the FDT structure. <list style="hanging">
<t hangText="*">"Transfer-Length" carries the Transfer-Length Object
Transmission Information element defined in <xref
target="RFC5052"></xref>.</t>
<t hangText="*">"FEC-OTI-FEC-Encoding-ID" carries the "FEC Encoding
ID" Object Transmission Information element defined in <xref
target="RFC5052"></xref>, as carried in the Codepoint field of the
ALC/LCT header.</t>
<t hangText="*">"FEC-OTI-FEC-Instance-ID" carries the "FEC Instance
ID" Object Transmission Information element defined in <xref
target="RFC5052"></xref> for Under-specified FEC Schemes.</t>
<t hangText="*">"FEC-OTI-Maximum-Source-Block-Length" carries the
"Maximum Source Block Length" Object Transmission Information
element defined in <xref target="RFC5052"></xref>, if required by
the FEC Scheme.</t>
<t hangText="*">"FEC-OTI-Encoding-Symbol-Length" carries the
"Encoding Symbol Length" Object Transmission Information element
defined in <xref target="RFC5052"></xref>, if required by the FEC
Scheme.</t>
<t hangText="*">"FEC-OTI-Max-Number-of-Encoding-Symbols" carries the
"Maximum Number of Encoding Symbols" Object Transmission Information
element defined in <xref target="RFC5052"></xref>, if required by
the FEC Scheme.</t>
<t hangText="*">"FEC-OTI-Scheme-specific-information" carries the
"encoded scheme-specific FEC Object Transmission Information" as
defined in <xref target="RFC5052"></xref>, if required by the FEC
Scheme.</t>
</list></t>
<t>In FLUTE, the FEC Encoding ID (8 bits) for a given TOI MUST be
carried in the Codepoint field of the ALC/LCT header. When the FEC
Object Transmission Information for this TOI is delivered through the
FDT, then the associated "FEC-OTI-FEC-Encoding-ID" attribute and the
Codepoint field of all packets for this TOI MUST be the same.</t>
</section>
<section anchor="desc-file-delivery-session"
title="Describing file delivery sessions">
<t>To start receiving a file delivery session, the receiver needs to
know transport parameters associated with the session. Interpreting
these parameters and starting the reception therefore represents the
entry point from which thereafter the receiver operation falls into the
scope of this specification. According to <xref
target="RFC5775"></xref>, the transport parameters of an ALC/LCT
session that the receiver needs to know are: <list style="hanging">
<t hangText="*">The source IP address;</t>
<t hangText="*">The number of channels in the session;</t>
<t hangText="*">The destination IP address and port number for each
channel in the session;</t>
<t hangText="*">The Transport Session Identifier (TSI) of the
session;</t>
<t hangText="*">An indication that the session is a FLUTE session.
The need to demultiplex objects upon reception is implicit in any
use of FLUTE, and this fulfills the ALC requirement of an indication
of whether or not a session carries packets for more than one object
(all FLUTE sessions carry packets for more than one object).</t>
</list></t>
<t>Optionally, the following parameters MAY be associated with the
session (Note, the list is not exhaustive): <list style="hanging">
<t hangText="*">The start time and end time of the session;</t>
<t hangText="*">FEC Encoding ID and FEC Instance ID when the default
FEC Encoding ID 0 is not used for the delivery of FDT;</t>
<t hangText="*">Content Encoding format if optional content encoding
of FDT Instance is used, e.g., compression;</t>
<t hangText="*">Some information that tells receiver, in the first
place, that the session contains files that are of interest;</t>
<t hangText="*">Definition and configuration of congestion control
mechanism for the session;</t>
<t hangText="*">Security parameters relevant for the session;</t>
<t hangText="*">FLUTE version number.</t>
</list></t>
<t>It is envisioned that these parameters would be described according
to some session description syntax (such as SDP <xref
target="RFC4566"></xref> or XML based) and held in a file which would be
acquired by the receiver before the FLUTE session begins by means of
some transport protocol (such as Session Announcement Protocol (SAP) <xref
target="RFC2974"></xref>, email, HTTP <xref target="RFC2616"></xref>,
SIP <xref target="RFC3261"></xref>, manual pre-configuration, etc.)
However, the way in which the receiver discovers the above-mentioned
parameters is out of scope of this document, as it is for LCT and ALC.
In particular, this specification does not mandate or exclude any
mechanism.</t>
</section>
<section anchor="sec-cons" title="Security Considerations">
<section anchor="sec-problem-statement" title="Problem Statement">
<t>A content delivery system is potentially subject to attacks.
Attacks may target: <list style="hanging">
<t hangText="*">the network (to compromise the routing
infrastructure, e.g., by creating congestion),</t>
<t hangText="*">the Content Delivery Protocol (CDP) (e.g., to
compromise the normal behavior of FLUTE), or</t>
<t hangText="*">the content itself (e.g., to corrupt the files
being transmitted).</t>
</list> These attacks can be launched either: <list style="hanging">
<t hangText="*">against the data flow itself (e.g., by sending
forged packets),</t>
<t hangText="*">against the session control parameters (e.g., by
corrupting the session description, the FDT Instances, or the
ALC/LCT control parameters) that are sent either in-band or
out-of-band, or</t>
<t hangText="*">against some associated building blocks (e.g., the
congestion control component).</t>
</list> In the following sections we provide more details on these
possible attacks and sketch some possible counter-measures. We provide
recommendations in <xref target="min-sec-recommendations"></xref>.</t>
</section>
<section anchor="sec-attacks-data-flow"
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="hanging">
<t hangText="*">attacks that are meant to give access to a
confidential file (e.g., in case of a non-free content) and</t>
<t hangText="*">attacks that try to corrupt the file being
transmitted (e.g., to inject malicious code within a file, or to
prevent a receiver from using a file, which is a kind of Denial of
Service, DoS).</t>
</list></t>
<section anchor="sec-access-confidential-files"
title="Access to confidential files">
<t>Access control to the file being transmitted is typically
provided by means of encryption. This encryption can be done over
the whole file i.e., before applying FEC protection (e.g., by the
content provider, before submitting the file to FLUTE), or be done
on a packet per packet basis (e.g., when IPsec/ESP is used <xref
target="RFC4303"></xref>, see <xref
target="min-sec-recommendations"></xref>). If confidentiality is a
concern, it is RECOMMENDED that one of these solutions be used.</t>
</section>
<section anchor="sec-file-corruption" title="File corruption">
<t>Protection against corruptions (e.g., if an attacker sends forged
packets) is achieved by means of a content integrity
verification/sender authentication scheme. This service can be
provided at the file level i.e., before applying content encoding and
forward error correction encoding. In that case a receiver has no
way to identify which symbol(s) is(are) corrupted if the file is
detected as corrupted. This service can also be provided at the
packet level i.e., after applying content encoding and forward error
correction encoding, on a packet by packet basis. In this case,
after removing all corrupted packets, the file may be in some cases
recovered from the remaining correct packets.</t>
<t>Integrity protection applied at the file level has the advantage
of lower overhead since only relatively few bits are added to
provide the integrity protection compared to the file size. However
it has the disadvantage that it cannot distinguish between correct
packets and corrupt packets and therefore correct packets, which may
form the majority of packets received, may be unusable. Integrity
protection applied at the packet level has the advantage that it can
distinguish between correct and corrupt packets at the cost of
additional per packet overhead.</t>
<t>Several techniques can provide this source authentication/content
integrity service: <list style="hanging">
<t hangText="*">at the file level, the file MAY be digitally
signed, for instance by using RSASSA-PKCS1-v1_5 <xref
target="RFC3447"></xref>. This signature enables a receiver to
check the file integrity, once this latter has been fully
decoded. Even if digital signatures are computationally
expensive, this calculation occurs only once per file, which is
usually acceptable;</t>
<t hangText="*">at the packet level, each packet can be
digitally signed <xref target="RMT-SIMPLE-AUTH"></xref>. A major
limitation is the high computational and transmission overheads
that this solution requires. To avoid this problem, the
signature may span a set of symbols (instead of a single one) in
order to amortize the signature calculation, but if a single
symbol is missing, the integrity of the whole set cannot be
checked;</t>
<t hangText="*">at the packet level, a Group Message
Authentication Code (MAC) <xref target="RFC2104"></xref><xref
target="RMT-SIMPLE-AUTH"></xref> scheme can be used, for
instance by using HMAC-SHA-256 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 hangText="*">at the packet level, TESLA <xref
target="RFC4082"></xref><xref target="RFC5776"></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 hangText="*">at the packet level, IPsec/ESP <xref
target="RFC4303"></xref> can be used to check the integrity and
authenticate the sender of all the packets being exchanged in a
session (see <xref
target="min-sec-recommendations"></xref>).</t>
</list> 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 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 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. Nonetheless, in case 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="sec-attacks-sessions"
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="hanging">
<t hangText="*">the attack can target the session description,</t>
<t hangText="*">the attack can target the FDT Instances,</t>
<t hangText="*">the attack can target the ALC/LCT parameters,
carried within the LCT header or</t>
<t hangText="*">the attack can target the FLUTE associated
building blocks, for instance the multiple rate congestion control
protocol.</t>
</list> The consequences of these attacks are potentially serious,
since they might compromise the behavior of content delivery system
itself.</t>
<section anchor="sec-attacks-sdp"
title="Attacks against the Session Description">
<t>A FLUTE 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 source authentication to ensure that receivers
only accept legitimate Session Descriptions from authorized senders.
How these measures are achieved is outside the scope of this
document since this session description is usually carried
out-of-band.</t>
</section>
<section anchor="sec-attacks-fdt"
title="Attacks against the FDT Instances">
<t>Corrupting the FDT Instances is one 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.</t>
<t>Corrupting the FDT Instances is also a way to make the reception
process more costly than it should be. This can be achieved by
changing the FEC Object Transmission Information when the FEC Object
Transmission Information is included in the FDT Instance. For
example, an attacker may corrupt the FDT Instance in such a way that
Reed-Solomon over GF(2^^16) be used instead of GF(2^^8) with FEC
Encoding ID 2. This may significantly increase the processing load
while compromising FEC decoding.</t>
<t>It is therefore RECOMMENDED that measures be taken to guarantee
the integrity and to check the sender's identity of the FDT
Instances. To that purpose, one of the counter-measures mentioned
above (<xref target="sec-file-corruption"></xref>) SHOULD be used.
These measures will either be applied on a packet level, or globally
over the whole FDT Instance object. Additionally, XML digital
signatures <xref target="RFC3275"></xref> are a way to protect
the FDT Instance by digitally signing it. When there is no packet
level integrity verification scheme, it is RECOMMENDED to rely on
XML digital signatures of the FDT Instances.</t>
</section>
<section anchor="sec-attacks-alc"
title="Attacks against the ALC/LCT parameters">
<t>By corrupting the ALC/LCT header (or header extensions) one can
execute attacks on underlying ALC/LCT implementation. For example,
sending forged ALC packets with the Close Session flag (A) set to
one can lead the receiver to prematurely close the session.
Similarly, sending forged ALC packets with the Close Object flag (B)
set to 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 the ALC packets
received. To that purpose, one of the counter-measures mentioned
above (<xref target="sec-file-corruption"></xref>) SHOULD be
used.</t>
</section>
<section anchor="sec-attacks-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 FLUTE, 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 FLUTE, it
is also RECOMMENDED that a packet level authentication scheme be
used, as explained in <xref target="sec-file-corruption"></xref>.
Some of them, like TESLA, only provide a delayed authentication
service, whereas congestion control requires a rapid reaction. It is
therefore RECOMMENDED <xref target="RFC5775"></xref> 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. 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 prevent
attacks launched from outside of the group.</t>
</section>
</section>
<section anchor="other-sec-considerations"
title="Other Security Considerations">
<t>Lastly, we note that the security considerations that apply to, and
are described in, ALC <xref target="RFC5775"></xref>, LCT <xref
target="RFC5651"/> and FEC <xref target="RFC5052"></xref> also
apply to FLUTE as FLUTE builds on those specifications. In addition,
any security considerations that apply to any congestion control
building block used in conjunction with FLUTE also apply to FLUTE.</t>
</section>
<section anchor="min-sec-recommendations"
title="Minimum Security Recommendations">
<t>We now introduce a mandatory to implement but not necessarily to
use security configuration, in the sense of <xref
target="RFC3365"></xref>. Since FLUTE relies on ALC/LCT, it inherits
the "baseline secure ALC operation" of <xref
target="RFC5775"></xref>. More precisely, security is achieved
by means of IPsec/ESP in transport mode. <xref
target="RFC4303"></xref> explains that ESP can be used to potentially
provide confidentiality, data origin authentication, content
integrity, anti-replay and (limited) traffic flow confidentiality.
<xref target="RFC5775"></xref> specifies that the data origin
authentication, content integrity and anti-replay services SHALL be
supported, and that the confidentiality service is RECOMMENDED. If a
short lived session MAY rely on manual keying, it is also RECOMMENDED
that an automated key management scheme be used, especially in case of
long lived sessions.</t>
<t>Therefore, the RECOMMENDED solution for FLUTE provides per-packet
security, with data origin authentication, integrity verification and
anti-replay. This is sufficient to prevent most of the in-band attacks
listed above. If confidentiality is required, a per-packet encryption
SHOULD also be used.</t>
</section>
</section>
<section anchor="iana-cons" title="IANA Considerations">
<t>This specification contains five separate items for IANA
Considerations: <list style="hanging">
<t hangText="1.">Registration Request for XML Schema of FDT
Instance.</t>
<t hangText="2.">Media-Type Registration Request for
application/fdt+xml.</t>
<t hangText="3.">Content Encoding Algorithm Registration
Request.</t>
<t hangText="4.">Registration of the EXT_FDT LCT Header Extension
Type</t>
<t hangText="5.">Registration of the EXT_CENC LCT Header Extension
Type</t>
</list></t>
<section anchor="reg-fdt-schema"
title="Registration Request for XML Schema of FDT Instance">
<t>Document <xref target="RFC3688"></xref> defines an IANA maintained
registry of XML documents used within IETF protocols. The following is
the registration request for the FDT XML schema.</t>
<t>Registrant Contact: Toni Paila (toni.paila (at) nokia.com)</t>
<t>XML: The XML Schema specified in <xref
target="fdt-syntax"></xref></t>
</section>
<section anchor="reg-fdt-mime"
title="Media-Type Registration Request for application/fdt+xml">
<t>This section provides the registration request, as per <xref
target="RFC4288"></xref>, <xref target="RFC4289"></xref> and
<xref target="RFC3023"></xref>, to be submitted to IANA
following IESG approval.</t>
<t>Type name: application</t>
<t>Subtype name: fdt+xml</t>
<t>Required parameters: none</t>
<t>Optional parameters: none</t>
<t>Encoding considerations: The fdt+xml type consists of UTF-8 ASCII
characters <xref target="RFC3629"></xref> and must be well-formed
XML.</t>
<t>Additional content and transfer encodings may be used with fdt+xml
files, with the appropriate encoding for any specific file being
entirely dependent upon the deployed application.</t>
<t>Restrictions on usage: Only for usage with FDT Instances which are
valid according to the XML schema of section 3.4.2.</t>
<t>Security considerations: fdt+xml data is passive, and does not
generally represent a unique or new security threat. However, there is
some risk in sharing any kind of data, in that unintentional
information may be exposed, and that risk applies to fdt+xml data as
well.</t>
<t>Interoperability considerations: None</t>
<t>Published specification: The present document including section
3.4.2. The specified FDT Instance functions as an actual media format
of use to the general Internet community and thus media type
registration under the Standards Tree is appropriate to maximize
interoperability.</t>
<t>Applications which use this media type: Not restricted to any
particular application</t>
<t>Additional information:</t>
<figure>
<artwork><![CDATA[
Magic number(s): none
File extension(s): An FDT Instance may use the extension ".fdt"
but this is not required.
Macintosh File Type Code(s): none
]]></artwork>
</figure>
<t>Person and email address to contact for further information: Toni
Paila (toni.paila (at) nokia.com)</t>
<t>Intended usage: Common</t>
<t>Author/Change controller: IETF</t>
</section>
<section anchor="reg-ext-cenc"
title="Content Encoding Algorithm Registration Request">
<t>Values of Content Encoding Algorithms are subject to IANA
registration. The value of Content Encoding Algorithm is a numeric
non-negative index. In this document, the range of values for Content
Encoding Algorithms is 0 to 255. This specification already assigns
the values 0, 1, 2 and 3 as described in section 3.4.3.</t>
<section anchor="iana-as-guide"
title="Explicit IANA Assignment Guidelines">
<t>This document defines a name-space called "Content Encoding
Algorithms".</t>
<t>IANA has established and manages the new registry for the
"FLUTE Content Encoding Algorithm" name-space. The values that can be
assigned within this name-space are numeric indexes in the range [0,
255], boundaries included. Assignment requests are granted on a
"Specification Required" basis as defined in <xref target="RFC5226"></xref>.
Note that the values 0, 1, 2 and 3 of this registry are already assigned
by this document as described in section 3.4.3.</t>
<t></t>
</section>
</section>
<section title="Registration of EXT_FDT LCT Header Extension Type">
<t>This document registers value 192 for the EXT_FDT LCT Header
Extension defined in <xref target="ext-fdt"></xref>.</t>
</section>
<section title="Registration of EXT_CENC LCT Header Extension Type">
<t>This document registers value 193 for the EXT_CENC LCT Header
Extension defined in <xref target="fdt-encoding"></xref>.</t>
</section>
</section>
<section anchor="acknow" title="Acknowledgments">
<t>The following persons have contributed to this specification: Brian
Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma,
Topi Pohjolainen, Lorenzo Vicisano, Mark Watson, David Harrington,
Ben Campbell, Stephen Farrell, Robert Sparks, Ronald Bonica and Francis Dupont.
The authors would like to thank all the contributors for their valuable work in reviewing
and providing feedback regarding this specification.</t>
</section>
<section anchor="contributors" title="Contributors">
<t>Jani Peltotalo<vspace /> Tampere University of Technology<vspace />
P.O. Box 553 (Korkeakoulunkatu 1)<vspace /> Tampere FIN-33101<vspace />
Finland<vspace /> Email: jani.peltotalo (at) tut.fi</t>
<t>Sami Peltotalo<vspace /> Tampere University of Technology<vspace />
P.O. Box 553 (Korkeakoulunkatu 1)<vspace /> Tampere FIN-33101<vspace />
Finland<vspace /> Email: sami.peltotalo (at) tut.fi</t>
<t>Magnus Westerlund<vspace /> Ericsson Research<vspace /> Ericsson
AB<vspace /> SE-164 80 Stockholm<vspace /> Sweden<vspace /> EMail:
magnus.westerlund (at) ericsson.com</t>
<t>Thorsten Lohmar<vspace /> Ericsson Research (EDD)<vspace /> Ericsson
Allee 1<vspace /> 52134 Herzogenrath<vspace /> Germany<vspace /> EMail:
thorsten.lohmar (at) ericsson.com</t>
</section>
<section anchor="change-log" title="Change Log">
<section title="RFC3926 to draft-ietf-rmt-flute-revised-12">
<t>Incremented FLUTE protocol version from 1 to 2, due to concerns
about backwards compatibility.
For instance, the LCT header changed between RFC 3451 and <xref target="RFC5651"/>.
In RFC 3451, the T and R fields of the LCT header respectively
indicate the presence of Sender Current Time and Expected Residual Time.
In <xref target="RFC5651"/>, these fields MUST be set to zero and MUST be ignored by receivers
(instead the EXT_TIME extension headers can convey this information if needed).
Thus, <xref target="RFC5651"/> is not backwards compatible with RFC 3451,
even though both have the same LCT version 1.
FLUTE version 1 as specified in <xref target="RFC3926"/> MUST use RFC 3451.
FLUTE version 2 as specified in this document MUST use <xref target="RFC5651"/>.
Therefore an implementation that relies on <xref target="RFC3926"/> and
RFC 3451 will not be backwards compatible with FLUTE as specified in this
document.</t>
<t>Updated dependencies to other RFCs to revised versions, e.g., changed
ALC reference from RFC 3450 to <xref target="RFC5775"/>, changed LCT reference from
RFC 3451 to <xref target="RFC5651"/>, etc.</t>
<t>Two additional items are added in the IANA considerations section,
specifically the registration of two values in the LCT Header Extension
Types registry (192 for EXT_FDT and 193 for EXT_CENC).</t>
<t>Added clarification for the use of FLUTE for unicast communications
in <xref target="weaknesses"></xref>.</t>
<t>Clarified how to reliably deliver the FDT in <xref
target="fdt-dynamics"></xref> and the possibility of using an
out-of-band delivery of FDT information.</t>
<t>Clarified how to address FDT Instance expiration time wraparound
with the notion of "epoch" of NTPv4 in <xref
target="fdt-dynamics"></xref>.</t>
<t>Clarified what should be considered as erroneous situations in
<xref target="ext-fdt"></xref> (definition of FDT Instance ID). In
particular a receiver MUST be ready to handle FDT Instance ID
wraparounds and missing FDT Instances.</t>
<t>Updated the security section to define IPsec/ESP as a mandatory to
implement security solution in <xref
target="min-sec-recommendations"></xref>.</t>
<t>Removed the 'Statement of Intent' from the <xref
target="intro"></xref>. The statement of intent was meant to clarify
the "Experimental" status of <xref target="RFC3926"/>. It does not apply to this draft
that is intended for "Standard Track" submission.</t>
<t>Added clarification on XML-DSIG in the end of <xref
target="file-delivery"></xref>.</t>
<t>Revised the use of word "complete" in the <xref
target="fdt"></xref>.</t>
<t>Clarified <xref target="overall-flute-packet"></xref> WRT "Encoding
Symbol(s) for FDT Instance".</t>
<t>Clarified the FDT Instance ID wrap-around in the end of <xref
target="ext-fdt"></xref>.</t>
<t>Clarification for "Complete FDT" in the <xref
target="fdt-syntax"></xref>.</t>
<t>Added semantics for the case two TOIs refer to same
Content-Location. Now it is in line how 3GPP and DVB interpret the
case.</t>
<t>In the <xref target="fdt-syntax"></xref> XML Schema of FDT instance
is modified to various advices. For example, extension by element was
missing but is now supported. Also namespace definition is changed to
URN format.</t>
<t>Clarified FDT-schema extensibility in the end of <xref
target="fdt-syntax"></xref>.</t>
<t>The CENC value allocation is added in the end of <xref
target="fdt-encoding"></xref>.</t>
<t><xref target="deliv-fec-oti"></xref> is modified so that EXT_FTI
and the FEC issues are replaced by a reference to LCT specification.
We count on revised LCT specification to specify the EXT_FTI.</t>
<t>Added a clarifying paragraph on the use of Codepoint in the very
end of <xref target="deliv-fec-oti"></xref>.</t>
<t>Reworked <xref target="iana-cons"></xref> - IANA Considerations.
Now it contains three IANA registration requests:
<list style="hanging">
<t hangText="*">Registration Request for XML Schema of FDT
Instance (urn:ietf:params:xml:schema:fdt)</t>
<t hangText="*">Media-Type Registration Request for
application/fdt+xml</t>
<t hangText="*">Content Encoding Algorithm Registration Request
(ietf:rmt:cenc)</t>
</list></t>
<t>Added <xref target="contributors"></xref> - Contributors.</t>
<t>Revised list of both Normative as well as Informative
references.</t>
<t>Added a clarification that receiver should ignore reserved bits of
Header Extension type 193 upon reception.</t>
<t>Minor changes to remove forward references (use before definition)
or refer to forward reference sections.</t>
<t>Elaborate on just what kind of networks cannot support FLUTE
congestion control (1.1.4)</t>
<t>In <xref target="fdt"></xref> revise "several"
(meaning 3-n vs. "couple" = 2) to "multiple" (meaning 2-n)</t>
<t>Move <xref target="fdt-dynamics"></xref> requirement to send
FDT more reliably than files, to a bulleted RECOMMENDED requirement,
making check-off easier for testers.</t>
<t>Sharpen <xref target="fdt-dynamics"></xref> definition that
future FDT file instances can "augment" (meaning enhance) rather
than "complement" (sometimes meaning negate, which is not allowed)
the file parameters.</t>
<t>Elaborate in <xref target="fdt-dynamics"></xref> and
<xref target="channels-cc-timing"></xref> that FEC Encoding ID = 0
is Compact No-code FEC, so that the reader doesn't have to search
other RFCs to understand these protocol constants used by FLUTE.</t>
<t>Require in <xref target="fdt-dynamics"></xref> that FLUTE receivers
SHALL NOT attempt to decode FDTs if they do not understand the FEC
Encoding ID</t>
<t>Remove restriction of <xref target="fdt-dynamics"></xref> in
bullet #4 that TOI=0 for the FDT, to be consistent with Appendix,
bullet 6, and elsewhere. An FDT is signaled by an FDT Instance ID,
NOT only by TOI = 0. </t>
<t>Standardize on the term "expiration time" and avoid using the
redundant but possibly confusing term "expiry time".</t>
<t>To interwork with experimental flute, stipulate in <xref
target="file-delivery-session"></xref> that only 1 instantiation of all
3 protocols FLUTE, ALC, and LCT, can be associated with a session
(source IP-Address, TSI) and mention in <xref
target="desc-file-delivery-session"></xref> that you may (optionally)
derive the FLUTE version from the file delivery session
description.</t>
<t>Use a software writing tool to lower reading grade level and
simplify <xref target="file-delivery-session"></xref>.</t>
</section>
</section>
</middle>
<back>
<references title="Normative references">
<!-- ================================ -->
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement
Levels</title>
<author initials="S." surname="Bradner">
<organization></organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="RFC" value="2119" />
<seriesInfo name="BCP" value="14" />
</reference>
&rfc5775; <!-- ALC -->
&rfc5651; <!-- LCT -->
&rfc5052; <!-- FEC BB -->
&rfc5445; <!-- Basic FEC BB -->
&rfc5905; <!-- NTPv4 -->
<!-- obsoleted by RFC 5905
<reference anchor="RFC.NTP">
<front>
<title>Network Time Protocol (Version 3), Specification,
Implementation and Analysis</title>
<author initials="D." surname="Mills">
<organization></organization>
</author>
<date month="March" year="1992" />
</front>
<seriesInfo name="RFC" value="1305" />
</reference>
-->
<reference anchor="RFC2616">
<front>
<title>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials="R." surname="Fielding">
<organization></organization>
</author>
<author initials="J." surname="Gettys">
<organization></organization>
</author>
<author initials="J." surname="Mogul">
<organization></organization>
</author>
<author initials="H." surname="Frystyk">
<organization></organization>
</author>
<author initials="L." surname="Masinter">
<organization></organization>
</author>
<author initials="P." surname="Leach">
<organization></organization>
</author>
<author initials="T." surname="Berners-Lee">
<organization></organization>
</author>
<date month="June" year="1999" />
</front>
<seriesInfo name="RFC" value="2616" />
</reference>
<reference anchor="XML-Schema-Part-1">
<front>
<title>XML Schema Part 1: Structures Second Edition</title>
<author initials="H." surname="Thompson">
<organization></organization>
</author>
<author initials="D." surname="Beech">
<organization></organization>
</author>
<author initials="M." surname="Maloney">
<organization></organization>
</author>
<author initials="N." surname="Mendelsohn">
<organization></organization>
</author>
<date month="October" year="2004" />
</front>
<seriesInfo name="W3C Recommendation, " value="http://www.w3.org/TR/xmlschema-1/" />
</reference>
<reference anchor="XML-Schema-Part-2">
<front>
<title>XML Schema Part 2: Datatypes Second Edition</title>
<author initials="P." surname="Biron">
<organization></organization>
</author>
<author initials="A." surname="Malhotra">
<organization></organization>
</author>
<date month="October" year="2004" />
</front>
<seriesInfo name="W3C Recommendation, " value="http://www.w3.org/TR/xmlschema-2/" />
</reference>
<reference anchor="RFC3023">
<front>
<title>XML Media Types</title>
<author fullname="M Murata" initials="M" surname="Murata">
<organization></organization>
</author>
<author fullname="S St.Laurent" initials="S" surname="St.Laurent">
<organization></organization>
</author>
<author fullname="D Kohn" initials="D" surname="Kohn">
<organization></organization>
</author>
<date month="January" year="2001" />
</front>
<seriesInfo name="RFC" value="3023" />
</reference>
<reference anchor="RFC3629">
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author fullname="F Yergeau" initials="F" surname="Yergeau">
<organization></organization>
</author>
<date month="November" year="2003" />
</front>
<seriesInfo name="RFC" value="3629" />
</reference>
<reference anchor="RFC5226">
<front>
<title>Guidelines for Writing an IANA Considerations Section in
RFCs</title>
<author fullname="T Narten" initials="T" surname="Narten">
<organization></organization>
</author>
<author fullname="H Alvestrand" initials="H" surname="Alvestrand">
<organization></organization>
</author>
<date month="May" year="2008" />
</front>
<seriesInfo name="RFC" value="5226" />
</reference>
<reference anchor="RFC3738">
<front>
<title>Wave and Equation Based Rate Control (WEBRC) Building
Block</title>
<author fullname="M. Luby" initials="M." surname="Luby">
<organization></organization>
</author>
<author fullname="V. Goyal" initials="V." surname="Goyal">
<organization></organization>
</author>
<date month="April" year="2004" />
</front>
<seriesInfo name="RFC" value="3738" />
<seriesInfo name="
Note: this reference is to a target document of a lower maturity
level and some caution should be used since it may be less stable
than the present document." value="" />
</reference>
<reference anchor="RFC4303">
<front>
<title>Encapsulating Security Payload (ESP)</title>
<author fullname="S Kent" initials="S" surname="Kent">
<organization></organization>
</author>
<date month="December" year="2005" />
</front>
<seriesInfo name="RFC" value="4303" />
</reference>
</references>
<references title="Informative references">
<!-- ================================== -->
&rfc3926;
&rfc2357;
&rfc3986;
<reference anchor="RFC1950">
<front>
<title>ZLIB Compressed Data Format Specification version 3.3</title>
<author initials="P." surname="Deutsch">
<organization></organization>
</author>
<author initials="J-L." surname="Gailly">
<organization></organization>
</author>
<date month="May" year="1996" />
</front>
<seriesInfo name="RFC" value="1950" />
</reference>
<reference anchor="RFC1951">
<front>
<title>DEFLATE Compressed Data Format Specification version
1.3</title>
<author initials="P." surname="Deutsch">
<organization></organization>
</author>
<date month="May" year="1996" />
</front>
<seriesInfo name="RFC" value="1951" />
</reference>
<reference anchor="RFC1952">
<front>
<title>GZIP file format specification version 4.3</title>
<author initials="P." surname="Deutsch">
<organization></organization>
</author>
<date month="May" year="1996" />
</front>
<seriesInfo name="RFC" value="1952" />
</reference>
<reference anchor="IANAmediatypes">
<front>
<title>IANA Media Types registry</title>
<author initials="" surname="">
<organization>IANA</organization>
</author>
</front>
<seriesInfo name="URL:" value="http://www.iana.org/assignments/media-types/" />
</reference>
<reference anchor="RFC2974">
<front>
<title>Session Announcement Protocol</title>
<author initials="M." surname="Handley">
<organization></organization>
</author>
<author initials="C." surname="Perkins">
<organization></organization>
</author>
<author initials="E." surname="Whelan">
<organization></organization>
</author>
<date month="October" year="2000" />
</front>
<seriesInfo name="RFC" value="2974" />
</reference>
<reference anchor="RFC4566">
<front>
<title>Session Description Protocol</title>
<author initials="M." surname="Handley">
<organization></organization>
</author>
<author initials="V." surname="Jacobson">
<organization></organization>
</author>
<author initials="C." surname="Perkins">
<organization></organization>
</author>
<date month="July" year="2006" />
</front>
<seriesInfo name="RFC" value="4566" />
</reference>
<reference anchor="RFC1112">
<front>
<title>Host Extensions for IP Multicasting</title>
<author initials="S." surname="Deering">
<organization></organization>
</author>
<date month="August" year="1989" />
</front>
<seriesInfo name="RFC" value="1112" />
<seriesInfo name="STD" value="5" />
</reference>
<reference anchor="PAPER.SSM">
<front>
<title>A Channel Model for Multicast, Ph.D. Dissertation, Stanford
University, Department of Computer Science, Stanford, California</title>
<author initials="H.W." surname="Holbrook">
<organization></organization>
</author>
<date month="August" year="2001" />
</front>
</reference>
<!-- replaced by RFC 5905, which also obsoletes RFC1305
<reference anchor="NTPv4">
<front>
<title>Network Time Protocol Version 4 Protocol And Algorithms
Specification</title>
<author fullname="William Kasch" initials="W" surname="Kasch">
<organization></organization>
</author>
<author fullname="David Mills" initials="D" surname="Mills">
<organization></organization>
</author>
<author fullname="Jack Burbank" initials="J" surname="Burbank">
<organization></organization>
</author>
<date day="9" month="October" year="2009" />
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-ntp-ntpv4-proto-13 (work in progress)" />
</reference>
-->
<reference anchor="RFC3365">
<front>
<title>Strong Security Requirements for Internet Engineering Task
Force Standard Protocols</title>
<author fullname="J. Schiller" initials="J." surname="Schiller">
<organization></organization>
</author>
<date month="August" year="2002" />
</front>
<seriesInfo name="BCP" value="61" />
<seriesInfo name="RFC" value="3365" />
</reference>
&rfc5751;
<!--
<reference anchor="RFC3851">
<front>
<title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version
3.1 Message Specification</title>
<author initials="B." surname="Ramsdell">
<organization></organization>
</author>
<date month="July" year="2004" />
</front>
<seriesInfo name="RFC" value="3851" />
</reference>
-->
<reference anchor="RFC3275">
<front>
<title>(Extensible Markup Language) XML-Signature Syntax and
Processing</title>
<author initials="D." surname="Eastlake">
<organization></organization>
</author>
<author initials="J." surname="Reagle">
<organization></organization>
</author>
<author initials="D." surname="Solo">
<organization></organization>
</author>
<date month="March" year="2002" />
</front>
<seriesInfo name="RFC" value="3275" />
</reference>
<reference anchor="RFC4288">
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author initials="N." surname="Freed">
<organization></organization>
</author>
<author initials="J." surname="Klensin">
<organization></organization>
</author>
<date month="December" year="2005" />
</front>
<seriesInfo name="RFC" value="4288" />
</reference>
<reference anchor="RFC4289">
<front>
<title>Multipurpose Internet Mail Extensions (MIME) Part Four:
Registration Procedures</title>
<author initials="N." surname="Freed">
<organization></organization>
</author>
<author initials="J." surname="Klensin">
<organization></organization>
</author>
<date month="December" year="2005" />
</front>
<seriesInfo name="RFC" value="4289" />
</reference>
<reference anchor="RFC3261">
<front>
<title>SIP: session initiation protocol</title>
<author initials="J." surname="Rosenberg">
<organization></organization>
</author>
<author initials="H." surname="Schulzrinne">
<organization></organization>
</author>
<author initials="G." surname="Camarillo">
<organization></organization>
</author>
<author initials="A. R." surname="Johnston">
<organization></organization>
</author>
<author initials="J." surname="Peterson">
<organization></organization>
</author>
<author initials="R." surname="Sparks">
<organization></organization>
</author>
<author initials="M." surname="Handley">
<organization></organization>
</author>
<author initials="E." surname="Schooler">
<organization></organization>
</author>
<date month="June" year="2002" />
</front>
<seriesInfo name="RFC" value="3261" />
</reference>
<reference anchor="RFC3688">
<front>
<title>The IETF XML Registry</title>
<author fullname="M Mealling" initials="M" surname="Mealling">
<organization></organization>
</author>
<date month="January" year="2004" />
</front>
<seriesInfo name="RFC" value="3688" />
</reference>
<reference anchor="RFC3447">
<front>
<title>Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography
Specifications Version 2.1</title>
<author fullname="J Jonsson" initials="J" surname="Jonsson">
<organization></organization>
</author>
<author fullname="B Kaliski" initials="B" surname="Kaliski">
<organization></organization>
</author>
<date month="February" year="2003" />
</front>
<seriesInfo name="RFC" value="3447" />
</reference>
<reference anchor="RFC2104">
<front>
<title>HMAC: Keyed-Hashing for Message Authentication</title>
<author fullname="H Krawczyk" initials="H" surname="Krawczyk">
<organization></organization>
</author>
<author fullname="M Bellare" initials="M" surname="Bellare">
<organization></organization>
</author>
<author fullname="R Canetti" initials="R" surname="Canetti">
<organization></organization>
</author>
<date month="February" year="1997" />
</front>
<seriesInfo name="RFC" value="2104" />
</reference>
<reference anchor="RFC4082">
<front>
<title>Timed Efficient Stream Loss-Tolerant Authentication (TESLA):
Multicast Source Authentication Transform Introduction</title>
<author fullname="A Perrig" initials="A" surname="Perrig">
<organization></organization>
</author>
<author fullname="R Canetti" initials="R" surname="Canetti">
<organization></organization>
</author>
<author fullname="J D Tygar" initials="J D" surname="Tygar">
<organization></organization>
</author>
<author fullname="B Briscoe" initials="B" surname="Briscoe">
<organization></organization>
</author>
<date month="June" year="2005" />
</front>
<seriesInfo name="RFC" value="4082" />
</reference>
&rfc5776;
<reference anchor="RMT-SIMPLE-AUTH">
<front>
<title>Simple Authentication Schemes for the ALC and NORM
Protocols</title>
<author initials="V." surname="Roca">
<organization></organization>
</author>
<date month="December" year="2011" />
</front>
<seriesInfo name=""
value="draft-ietf-rmt-simple-auth-for-alc-norm-06.txt (work in progress)" />
</reference>
</references>
<section title="Receiver operation (informative)">
<t>This section gives an example how the receiver of the file delivery
session may operate. Instead of a detailed state-by-state specification
the following should be interpreted as a rough sequence of an envisioned
file delivery receiver. <list style="format %d.">
<t>The receiver obtains the description of the file delivery session
identified by the pair: (source IP address, Transport Session
Identifier). The receiver also obtains the destination IP addresses
and respective ports associated with the file delivery session.</t>
<t>The receiver joins the channels in order to receive packets
associated with the file delivery session. The receiver may schedule
this join operation utilizing the timing information contained in a
possible description of the file delivery session.</t>
<t>The receiver receives ALC/LCT packets associated with the file
delivery session. The receiver checks that the packets match the
declared Transport Session Identifier. If not, packets are silently
discarded.</t>
<t>While receiving, the receiver demultiplexes packets based on
their TOI and stores the relevant packet information in an
appropriate area for recovery of the corresponding file. Multiple
files can be reconstructed concurrently.</t>
<t>Receiver recovers an object. An object can be recovered when an
appropriate set of packets containing Encoding Symbols for the
transmission object have been received. An appropriate set of
packets is dependent on the properties of the FEC Encoding ID and
FEC Instance ID, and on other information contained in the FEC
Object Transmission Information.</t>
<t>Objects with TOI = 0 are reserved for FDT Instances.
All FDT Instances are signaled by including an EXT_FDT
header extension in the LCT header. The EXT_FDT header
contains an FDT Instance ID (i.e., an FDT version number.)
If the object has an FDT Instance ID 'N', the receiver
parses the payload of the instance 'N' of FDT and updates
its FDT database accordingly.</t>
<t>If the object recovered is not an FDT Instance but a file, the
receiver looks up its FDT database to get the properties described
in the database, and assigns the file the given properties. The
receiver also checks that the received content length matches with
the description in the database. Optionally, if MD5 checksum has
been used, the receiver checks that the calculated MD5 matches the
description in the FDT database.</t>
<t>The actions the receiver takes with imperfectly received files
(missing data, mismatching digestive, etc.) is outside the scope of
this specification. When a file is recovered before the associated
file description entry is available, a possible behavior is to wait
until an FDT Instance is received that includes the missing
properties.</t>
<t>If the file delivery session end time has not been reached go
back to 3. Otherwise end.</t>
</list></t>
</section>
<section title="Example of FDT Instance (informative)">
<figure>
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<FDT-Instance xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:fdt
ietf-flute-fdt.xsd"
Expires="2890842807">
<File
Content-Location="http://www.example.com/menu/tracklist.html"
TOI="1"
Content-Type="text/html"/>
<File
Content-Location="http://www.example.com/tracks/track1.mp3"
TOI="2"
Content-Length="6100"
Content-Type="audio/mp3"
Content-Encoding="gzip"
Content-MD5="+VP5IrWploFkZWc11iLDdA=="
Some-Private-Extension-Tag="abc123"/>
</FDT-Instance>
]]></artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:10:33 |