One document matched: draft-ietf-rmt-flute-revised-08.xml
<?xml version='1.0'?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<!DOCTYPE rfc SYSTEM 'rfcXXXX.dtd'>
<?rfc toc='yes'?>
<?rfc compact='yes'?>
<?rfc symrefs='no'?>
<?rfc subcompact='no'?>
<rfc ipr="pre5378Trust200902" docName="draft-ietf-rmt-flute-revised-08" obsoletes="3926" category="std">
<!--<?rfc strict="yes" ?>-->
<front>
<title abbrev='FLUTE'>FLUTE - File Delivery over Unidirectional Transport</title>
<author initials='T.' surname='Paila' fullname='Toni 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 initials='R.' surname='Walsh' fullname='Rod Walsh'>
<organization>Nokia</organization>
<address>
<postal>
<street>Visiokatu 1</street>
<city>Tampere</city>
<code>FIN-33720</code>
<country>Finland</country>
</postal>
<email>rod.walsh@nokia.com</email>
</address>
</author>
<author initials='M.' surname='Luby' fullname='Michael Luby'>
<organization>Digital Fountain</organization>
<address>
<postal>
<street>Qualcomm, Inc.</street>
<street>3165 Kifer Rd.</street>
<city>Santa Clara</city> <region>CA</region>
<code>95051</code>
<country>US</country>
</postal>
<email>luby@qualcomm.com</email>
</address>
</author>
<author initials='V.' surname='Roca' fullname='Vincent 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 initials='R.' surname='Lehtonen' fullname='Rami 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 month='December' year='2009' />
<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 1, a protocol for unidirectional delivery of files over the Internet.
The specification builds on Asynchronous Layered Coding (ALC), version 1 <xref target='ID.ALC-revised' />,
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 signalling of the transport parameters of the ALC session.</t>
<t hangText='-'>In-band signalling 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. The
first appendix describes an envisioned receiver operation for the receiver of the file delivery session. The
second appendix gives an example of File Delivery Table.</t>
<t>This specification contains part of the definitions necessary to fully specify a Reliable Multicast Transport
protocol in accordance with RFC2357.</t>
<t>This document obsoletes RFC3926 which contained a previous version of this specification and was
published in the "Experimental" category.
This Proposed Standard specification is thus based on RFC3926 updated according to accumulated experience
and growing protocol maturity since the publication of 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 RFC3926 and this document listed in <xref target='change-log'/>.</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='RFC.SDP' /> 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 ALC building block
<xref target='ID.ALC-revised' /> and to any additional building blocks that FLUTE uses also apply to
FLUTE.</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. FLUTE inherently works with all 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='RFC.ASM' /> and the
Source-Specific Multicast (SSM) <xref target='PAPER.SSM' />.</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>Some networks are not amenable to some congestion control protocols that could be used with FLUTE.
In particular, for a satellite or wireless network, there may be no mechanism for receivers to
effectively reduce their reception rate since there may be a fixed transmission rate allocated to
the session.</t>
<t>FLUTE can also be used for point-to-point (unicast) communications.
At a minimum, implementions of ALC MUST support the WEBRC <xref target="RFC.3738"/> multiple rate
congestion control scheme <xref target="ID.ALC-revised"/>.
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 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 RFC 2119
<xref target='RFC.2119'/>.</t>
<t>The terms "object" and "transmission object" are consistent with the definitions in ALC
<xref target='ID.ALC-revised'/> and LCT <xref target='RFC.LCT'/>. 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='ID.ALC-revised'/> 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. This identifier may be globally unique. The
identifier may also 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 MIME media type (usually, this can also be concluded from the extension
of the file name). In the above example: "text/plain". If an explicit value for the MIME type
is provided separately from the file extension and does not match the MIME type of the file
extension then the explicitly provided value MUST be used as the MIME type.</t>
<t hangText='*'>File size, expressed in bytes. 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='RFC.ZLIB' />. 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='RFC.SMIME' /> as the content encoding type for files with this
authentication wrapper, and one could use XML-DSIG <xref target='RFC.XML-DSIG' /> to digitally
sign an FDT Instance. XML-DSIG can also be used to provide tamper prevention e.g. on the
Content-Location field.</t>
</list>
</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='RFC.LCT' />.
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 packets with ALC/LCT headers 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). The TSI is
scoped by the source IP address, and the (source IP address, TSI) pair uniquely identifies a session,
i.e., the receiver uses this pair carried in each packet to uniquely identify from which session the
packet was received. In case multiple objects are carried within a session, the Transmission Object
Identifier (TOI) field within the ALC/LCT header identifies from which object the data in the packet was
generated. Note that each object is associated with a unique TOI within the scope of a session.</t>
<t>If the sender is not assigned a permanent IP address accessible to receivers, but instead, packets that
can be received by receivers containing a temporary IP address for packets sent by the sender, then the TSI
is scoped by this temporary 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 that is accessible to receivers, and in this case the TSI is scoped by the temporary IP
address assigned by the NAT that will appear in packets received by the receiver. As another example,
the sender may send its original packets using IPv6, but some portions of the network may not be IPv6
capable and 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 a
permanent IP address or a temporary 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 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 RFC 3451 <xref target='RFC.LCT' /> for the LCT definition
of the Close Session flag, and see Section 4.2 of RFC 3450 <xref target='ID.ALC-revised' /> for an example of
its use 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.</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 is included in each ALC/LCT data packet during the delivery of the file, and thus the TOI carried in the
file description entry is how the receiver determines which ALC/LCT data packets contain information about
which 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, is not considered a 'file' belonging to the file
delivery session. Handling of these unmapped TOIs (TOIs that are not resolved by the FDT) is out of scope
of this specification.</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, or
complement any other FDT Instance. A certain FDT Instance may be repeated several 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 FDT database is an abstract concept, the structure and the maintaining 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
for FDT Instances is outside the scope of this specification.</t>
<t hangText='*'>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. Any ALC/LCT packet carrying FDT Instance
(indicated by TOI = 0) 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
prior to the sending of the described file within a file delivery session. </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 complement 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 a 32 bit data field. The value of the data field represents the 32 most
significant bits of a 64 bit Network Time Protocol (NTP) <xref target='RFC.NTP' /> 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="NTPv4"/>.
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 easily determine to which (136 year) epoch the
FDT Instance expiration time value pertains to.</t>
<!-- Handling of wraparound of the 32 bit time is outside the scope of NTP and FLUTE.</t> -->
<t hangText='*'>The receiver SHOULD 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 expiry 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
FEC Encoding ID 0 <xref target='RFC.FECSchemes' /> 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>
</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,
i.e., it is RECOMMENDED that FDT Instances be managed in such a way that a receiver will be able to recover at
least one FDT Instance describing a file delivered within the file delivery session with as much or greater
reliability as the receiver is able to receive enough packets containing encoding symbols to recover the file.
</t>
<t>
From this point of view, the way a given FDT Instance is transmitted has great impacts.
As an example, one way to satisfy this recommendation is to repeat FDT Instances describing the file often enough.
As another example, 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.
The way the FDT is delivered as FDT Instances has also great impacts.
As an example, a way to satisfy this recommendation is to use an FDT Instance that describes all the files
being transmitted at that time, and to transmit this FDT Instance reliably, as explained above.
If instead those files are described in separate FDT Instances, another way to satisfy this recommendation
is to transmit all the relevant FDT Instances reliably, as explained above.
</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>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. Thus, it is RECOMMENDED
that FDT Instances describing a file be sent with at least as much reliability within a session (more often
or with more FEC protection) as the files they describe. In particular, if FDT Instances are longer than
one packet payload in length it is RECOMMENDED that an FEC code that provides protection against loss be
used for delivering FDT Instances. How often the description of a file is sent in an FDT Instance or how
much FEC protection is provided for each FDT Instance (if the FDT Instance is longer than one packet
payload) is dependent on the particular application and outside the scope of this document.</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 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='ID.ALC-revised' />, all ALC/LCT packets are sent using UDP.</t>
<figure title="Overall FDT Packet" anchor="overall-flute-packet">
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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>FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI specific LCT header extension
<xref target='RFC.LCT' />. The Header Extension Type (HET) for the extension is 192. Its
format is defined below:</t>
<figure anchor='fig-ext-fdt'>
<artwork>
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 1. 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 '1'.</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. A new FDT Instance reusing a previous
FDT Instance ID number, due to wraparound, does not implicitly expire the previous FDT Instance with the same ID.
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.
Receiver behavior when receiving an FDT Instance that reuses an FDT Instance ID value that is currently
used by a non expired FDT Instance is outside the scope of this specification and left to individual
implementations of FLUTE.
However a receiver MUST be ready to handle FDT Instance ID wraparound and situations where
missing FDT Instance IDs result in increments larger than one.</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 value to a smaller FDT Instance value occurs, the smaller FDT Instance value
is considered logically higher than the greater FDT Instance value. A new FDT Instance reusing a previous
FDT Instance ID number, due to wraparound, may not implicitly expire the previous FDT Instance with the same ID.
Mandatory receiver behavior for handling FDT Instance ID wraparound and other
special situations (for example, missing FDT Instance IDs resulting in larger increments than one) is
outside the scope of this specification and left to individual implementations of FLUTE.</t>
-->
</section>
<section title='Syntax of FDT Instance' anchor='fdt-syntax'>
<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 expiry 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="RFC.HTTP11"/>. 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='*'>Where the MIME type is described, the attribute "Content-Type" MUST be used for the
purpose as defined in <xref target='RFC.HTTP11' />.</t>
<t hangText='*'>Where the length is described, the attribute "Content-Length" MUST be used for the purpose
as defined in <xref target='RFC.HTTP11' />. The transfer length is defined to be the length
of the object transported in bytes. 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 bytes 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='*'>Where the content encoding scheme is described, the attribute "Content-Encoding" MUST be used
for the purpose as defined in <xref target='RFC.HTTP11' />.</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='RFC.HTTP11' />.</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 target='XML-Schema-Part-2'/>
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.).</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='RFC.HTTP11' /> or another well-known
specification.</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, ALC PI specific LCT header extension
<xref target='RFC.LCT' />. 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>
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='RFC.ZLIB' />,
DEFLATE <xref target='RFC.DEFLATE' /> and GZIP <xref target='RFC.GZIP' /> respectively.</t>
<t>Reserved, 16 bits:</t>
<t>This field MUST be set to all '0'. This field SHOULD 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 FLUTE is envisioned
to be applied.
<list style="hanging">
<t hangText='(a)'>Use a single channel and a single-rate congestion control protocol.</t>
<t hangText='(b)'>Use 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 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 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
FEC Encoding ID 0 <xref target='RFC.FECSchemes' /> 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='RFC.FECBB' /> 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='ID.ALC-revised' />
and the use of FDT. The latter method is specified in this section.</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 prioritizes 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='RFC.FECBB' />.</t>
<t hangText='*'>"FEC-OTI-FEC-Encoding-ID" carries the "FEC Encoding ID" Object Transmission Information element defined in <xref target='RFC.FECBB' />, 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='RFC.FECBB' /> 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='RFC.FECBB' />, 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='RFC.FECBB' />, 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='RFC.FECBB' />, 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='RFC.FECBB' />, 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='ID.ALC-revised' />, 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>
</list>
</t>
<t>It is envisioned that these parameters would be described according to some session description syntax (such as
SDP <xref target='RFC.SDP'/> 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 <xref target='RFC.SAP'/>,
email, HTTP <xref target='RFC.HTTP11' />, SIP <xref target='RFC.SIP'/>, 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 behaviour 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 finally provide recommendations in <xref target="min-sec-recommendations"/>.
</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 (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="RFC.4303"/>, see <xref target="min-sec-recommendations"/>). 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, but 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. In this case, after removing all corrupted packets, the file may be in some cases recovered. 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="RFC.3447"/>. 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"/>. 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="RFC.2104"/><xref target="RMT-SIMPLE-AUTH"/> 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="RFC.4082"/><xref target="MSEC-TESLA"/> 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="RFC.4303"/> 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"/>).</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"/>) 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="RFC.XML-DSIG"/> 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"/>) 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"/>. Some of them, like TESLA, only provide a delayed authentication service, whereas congestion control requires a rapid reaction. It is therefore RECOMMENDED <xref target='ID.ALC-revised' /> 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='ID.ALC-revised' />, LCT <xref target='RFC.LCT' /> and FEC <xref target='RFC.FECBB' /> 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="RFC.3365"/>.
Since FLUTE relies on ALC/LCT, it inherits the "baseline secure ALC operation" of <xref target="ID.ALC-revised"/>.
More precisely, security is achieved by means of IPsec/ESP in transport mode.
<xref target='RFC.4303'/> explains that ESP can be used to potentially provide confidentiality, data origin
authentication, content integrity, anti-replay and (limited) traffic flow confidentiality.
<xref target="ID.ALC-revised"/> specifies that the data origin authentication, content integrity and
anti-replay services SHALL be used, 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 three separate items for IANA Considerations:
<list style='hanging'>
<t hangText='1.'>Registration Request for XML Schema of FDT Instance.</t>
<!-- (urn:ietf:params:xml:schema:fdt).</t> -->
<t hangText='2.'>Media-Type Registration Request for application/fdt+xml.</t>
<t hangText='3.'>Content Encoding Algorithm Registration Request.</t>
<!--(ietf:rmt:cenc).</t> -->
</list>
</t>
<section anchor='reg-fdt-schema' title='Registration Request for XML Schema of FDT Instance'>
<t>Document <xref target="RFC.3688" /> 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>URI: urn:ietf:params:xml:schema:fdt</t> -->
<t>Registrant Contact: Toni Paila (toni.paila (at) nokia.com)</t>
<t>XML: The XML Schema specified in <xref target="fdt-syntax"/> </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='RFC.MIME4a' />, <xref target='RFC.MIME4b' /> and
<xref target='RFC.XML-Media-Types' />, 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='RFC.UTF8' /> 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 dependant 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>
<!--
named:</t>
<figure>
<artwork><![CDATA[
ietf:rmt:cenc]]>
</artwork>
</figure>
<t>IANA has established and manages the new registry for the
"ietf:rmt:cenc" name-space. The values that can be assigned
within the "ietf:rmt:cenc" name-space are numeric indexes in
the range [0, 255], boundaries included. Assignment requests are
granted on a "Specification Required" basis as defined in RFC 2434
<xref target='RFC.Guidelines-Iana-Section' />. Note that the values 0,
1, 2 and 3 of "ietf:rmt:cenc" are already assigned by this document as
described in section 3.4.3.</t>
-->
<t>IANA has established and manages the new registry for the
"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 RFC 2434
<xref target='RFC.Guidelines-Iana-Section' />. 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>
</section>
</section>
</section>
<section anchor='acknow' title='Acknowledgements'>
<t>The following persons have contributed to this specification: Brian Adamson, Mark Handley, Esa Jalonen,
Roger Kermode, Juha-Pekka Luoma, Topi Pohjolainen, Lorenzo Vicisano, and Mark Watson. 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, Germany<vspace />
EMail: thorsten.lohmar (at) ericsson.com</t>
</section>
<section title='Change Log' anchor='change-log'>
<section title='RFC3926 to draft-ietf-rmt-flute-revised-08'>
<t>Added clarification for the use of FLUTE for unicast communications in <xref target="weaknesses"/>.</t>
<t>Clarified how to reliably deliver the FDT in <xref target='fdt-dynamics'/>.</t>
<t>Clarified how to address FDT Instance expiry time wraparound with the notion of "epoch"
of NTPv4 in <xref target='fdt-dynamics'/>.</t>
<t>Clarified what should be considered as erroneous situations in <xref target='ext-fdt'/>
(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"/>.</t>
<t>Removed the 'Statement of Intent' from the <xref target='intro'/>. The statement
of intent was meant to clarify the "Experimental" status of 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'/>.</t>
<t>Revised the use of word "complete" in the <xref target='fdt'/>.</t>
<t>Clarified <xref target='overall-flute-packet'/> WRT "Encoding Symbol(s) for FDT Instance".</t>
<t>Clarified the FDT Instance ID wrap-around in the end of <xref target='ext-fdt'/>.</t>
<t>Clarification for "Complete FDT" in the <xref target='fdt-syntax'/>.</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'/> 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'/>.</t>
<t>The CENC value allocation is added in the end of <xref target='fdt-encoding'/>.</t>
<t><xref target='deliv-fec-oti'/> 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'/>.</t>
<t>Reworked <xref target='iana-cons'/> - 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'/> - 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>
</section>
</section>
</middle>
<back>
<references title='Normative references'>
<reference anchor='RFC.2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner'>
<organization />
</author>
<date month='March' year='1997' />
</front>
<seriesInfo name='RFC' value='2119' />
<seriesInfo name='BCP' value='14' />
</reference>
<reference anchor='ID.ALC-revised'>
<front>
<title>Asynchronous Layered Coding (ALC) Protocol Instantiation</title>
<author initials='M.' surname='Luby'>
<organization />
</author>
<author initials='M.' surname='Watson'>
<organization />
</author>
<author initials='L.' surname='Vicisano'>
<organization />
</author>
<date month='November' year='2009' />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-rmt-pi-alc-revised-10"/>
<format type="TXT"
target="http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-alc-revised-10.txt" />
</reference>
<reference anchor='RFC.LCT'>
<front>
<title>Layered Coding Transport (LCT) Building Block</title>
<author initials='M.' surname='Luby'>
<organization />
</author>
<author initials='M.' surname='Watson'>
<organization />
</author>
<author initials='L.' surname='Vicisano'>
<organization />
</author>
<date month='October' year='2009' />
</front>
<seriesInfo name='RFC' value='5651' />
</reference>
<reference anchor='RFC.FECBB'>
<front>
<title>Forward Error Correction (FEC) Building Block</title>
<author initials='M.' surname='Watson'>
<organization />
</author>
<author initials='M.' surname='Luby'>
<organization />
</author>
<author initials='L.' surname='Vicisano'>
<organization />
</author>
<date month='August' year='2007' />
</front>
<seriesInfo name="RFC" value="5052"/>
</reference>
<reference anchor='RFC.FECSchemes'>
<front>
<title>Basic Forward Error Correction (FEC) Schemes</title>
<author initials='M.' surname='Watson'>
<organization />
</author>
<date month='March' year='2009' />
</front>
<seriesInfo name="RFC" value="5445"/>
</reference>
<reference anchor='RFC.NTP'>
<front>
<title>Network Time Protocol (Version 3), Specification, Implementation and Analysis</title>
<author initials='D.' surname='Mills'>
<organization />
</author>
<date month='March' year='1992' />
</front>
<seriesInfo name='RFC' value='1305' />
</reference>
<reference anchor='RFC.HTTP11'>
<front>
<title>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials='R.' surname='Fielding'>
<organization />
</author>
<author initials='J.' surname='Gettys'>
<organization />
</author>
<author initials='J.' surname='Mogul'>
<organization />
</author>
<author initials='H.' surname='Frystyk'>
<organization />
</author>
<author initials='L.' surname='Masinter'>
<organization />
</author>
<author initials='P.' surname='Leach'>
<organization />
</author>
<author initials='T.' surname='Berners-Lee'>
<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</title>
<author initials='H.' surname='Thompson'>
<organization />
</author>
<author initials='D.' surname='Beech'>
<organization />
</author>
<author initials='M.' surname='Maloney'>
<organization />
</author>
<author initials='N.' surname='Mendelsohn'>
<organization />
</author>
<date month='May' year='2001' />
</front>
<seriesInfo name='W3C' value='Recommendation' />
</reference>
<reference anchor='XML-Schema-Part-2'>
<front>
<title>XML Schema Part 2: Datatypes</title>
<author initials='P.' surname='Biron'>
<organization />
</author>
<author initials='A.' surname='Malhotra'>
<organization />
</author>
<date month='May' year='2001' />
</front>
<seriesInfo name='W3C' value='Recommendation' />
</reference>
<reference anchor="RFC.XML-Media-Types">
<front>
<title>XML Media Types</title>
<author initials="M" surname="Murata" fullname="M Murata">
<organization />
</author>
<author initials="S" surname="St.Laurent" fullname="S St.Laurent">
<organization />
</author>
<author initials="D" surname="Kohn" fullname="D Kohn">
<organization />
</author>
<date month="January" year="2001" />
</front>
<seriesInfo name="RFC" value="3023" />
</reference>
<reference anchor="RFC.UTF8">
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials="F" surname="Yergeau" fullname="F Yergeau">
<organization />
</author>
<date month="November" year="2003" />
</front>
<seriesInfo name="RFC" value="3629" />
</reference>
<reference anchor="RFC.Guidelines-Iana-Section">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials="T" surname="Narten" fullname="T Narten">
<organization />
</author>
<author initials="H" surname="Alvestrand" fullname="H Alvestrand">
<organization />
</author>
<date month="May" year="2008" />
</front>
<seriesInfo name="RFC" value="5226" />
</reference>
<reference anchor='RFC.ZLIB'>
<front>
<title>ZLIB Compressed Data Format Specification version 3.3</title>
<author initials='P.' surname='Deutsch'>
<organization />
</author>
<author initials='J-L.' surname='Gailly'>
<organization />
</author>
<date month='May' year='1996' />
</front>
<seriesInfo name='RFC' value='1950' />
</reference>
<reference anchor='RFC.DEFLATE'>
<front>
<title>DEFLATE Compressed Data Format Specification version 1.3</title>
<author initials='P.' surname='Deutsch'>
<organization />
</author>
<date month='May' year='1996' />
</front>
<seriesInfo name='RFC' value='1951' />
</reference>
<reference anchor='RFC.GZIP'>
<front>
<title>GZIP file format specification version 4.3</title>
<author initials='P.' surname='Deutsch'>
<organization />
</author>
<date month='May' year='1996' />
</front>
<seriesInfo name='RFC' value='1952' />
</reference>
</references>
<references title='Informative references'>
<reference anchor='RFC.SAP'>
<front>
<title>Session Announcement Protocol</title>
<author initials='M.' surname='Handley'>
<organization />
</author>
<author initials='C.' surname='Perkins'>
<organization />
</author>
<author initials='E.' surname='Whelan'>
<organization />
</author>
<date month='October' year='2000' />
</front>
<seriesInfo name='RFC' value='2974' />
</reference>
<reference anchor='RFC.SDP'>
<front>
<title>Session Description Protocol</title>
<author initials='M.' surname='Handley'>
<organization />
</author>
<author initials='V.' surname='Jacobson'>
<organization />
</author>
<author initials='C.' surname='Perkins'>
<organization />
</author>
<date month='July' year='2006' />
</front>
<seriesInfo name='RFC' value='4566' />
</reference>
<reference anchor='RFC.ASM'>
<front>
<title>Host Extensions for IP Multicasting</title>
<author initials='S.' surname='Deering'>
<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 />
</author>
<date month='August' year='2001' />
</front>
</reference>
<reference anchor='NTPv4'>
<front>
<title>Network Time Protocol Version 4 Protocol And Algorithms Specification</title>
<author initials='W' surname='Kasch' fullname='William Kasch'> <organization /> </author>
<author initials='D' surname='Mills' fullname='David Mills'> <organization /> </author>
<author initials='J' surname='Burbank' fullname='Jack Burbank'> <organization /> </author>
<date month='October' day='9' year='2009' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-ntp-ntpv4-proto-13 (work in progress)' />
</reference>
<reference anchor='RFC.3365'>
<front>
<title>Strong Security Requirements for Internet Engineering Task Force Standard Protocols</title>
<author initials='J.' surname='Schiller' fullname='J. Schiller'><organization /></author>
<date year='2002' month='August' />
</front>
<seriesInfo name='BCP' value='61' />
<seriesInfo name='RFC' value='3365' />
</reference>
<reference anchor='RFC.SMIME'>
<front>
<title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification</title>
<author initials='B.' surname='Ramsdell'>
<organization />
</author>
<date month='July' year='2004' />
</front>
<seriesInfo name='RFC' value='3851' />
</reference>
<reference anchor='RFC.XML-DSIG'>
<front>
<title>(Extensible Markup Language) XML-Signature Syntax and Processing</title>
<author initials='D.' surname='Eastlake'>
<organization />
</author>
<author initials='J.' surname='Reagle'>
<organization />
</author>
<author initials='D.' surname='Solo'>
<organization />
</author>
<date month='March' year='2002' />
</front>
<seriesInfo name='RFC' value='3275' />
</reference>
<reference anchor='RFC.MIME4a'>
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author initials='N.' surname='Freed'>
<organization />
</author>
<author initials='J.' surname='Klensin'>
<organization />
</author>
<date month='December' year='2005' />
</front>
<seriesInfo name='RFC' value='4288' />
</reference>
<reference anchor='RFC.MIME4b'>
<front>
<title>Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures</title>
<author initials='N.' surname='Freed'>
<organization />
</author>
<author initials='J.' surname='Klensin'>
<organization />
</author>
<date month='December' year='2005' />
</front>
<seriesInfo name='RFC' value='4289' />
</reference>
<reference anchor='RFC.SIP'>
<front>
<title>SIP: session initiation protocol</title>
<author initials='J.' surname='Rosenberg'>
<organization />
</author>
<author initials='H.' surname='Schulzrinne'>
<organization />
</author>
<author initials='G.' surname='Camarillo'>
<organization />
</author>
<author initials='A. R.' surname='Johnston'>
<organization />
</author>
<author initials='J.' surname='Peterson'>
<organization />
</author>
<author initials='R.' surname='Sparks'>
<organization />
</author>
<author initials='M.' surname='Handley'>
<organization />
</author>
<author initials='E.' surname='Schooler'>
<organization />
</author>
<date month='June' year='2002' />
</front>
<seriesInfo name='RFC' value='3261' />
</reference>
<reference anchor="RFC.3738">
<front>
<title>Wave and Equation Based Rate Control (WEBRC) Building Block</title>
<author initials='M.' surname='Luby' fullname='M. Luby'>
<organization /></author>
<author initials='V.' surname='Goyal' fullname='V. Goyal'>
<organization /></author>
<date year='2004' month='April' />
</front>
<seriesInfo name='RFC' value='3738' />
</reference>
<reference anchor="RFC.3688">
<front>
<title>The IETF XML Registry</title>
<author initials="M" surname="Mealling" fullname="M Mealling">
<organization />
</author>
<date month="January" year="2004" />
</front>
<seriesInfo name="RFC" value="3688" />
</reference>
<reference anchor="RFC.3447">
<front>
<title>Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</title>
<author initials="J" surname="Jonsson" fullname="J Jonsson">
<organization />
</author>
<author initials="B" surname="Kaliski" fullname="B Kaliski">
<organization />
</author>
<date month="February" year="2003" />
</front>
<seriesInfo name="RFC" value="3447" />
</reference>
<reference anchor="RFC.4303">
<front>
<title>Encapsulating Security Payload (ESP)</title>
<author initials="S" surname="Kent" fullname="S Kent">
<organization />
</author>
<date month="December" year="2005" />
</front>
<seriesInfo name="RFC" value="4303" />
</reference>
<reference anchor="RFC.2104">
<front>
<title>HMAC: Keyed-Hashing for Message Authentication</title>
<author initials="H" surname="Krawczyk" fullname="H Krawczyk">
<organization />
</author>
<author initials="M" surname="Bellare" fullname="M Bellare">
<organization />
</author>
<author initials="R" surname="Canetti" fullname="R Canetti">
<organization />
</author>
<date month="February" year="1997" />
</front>
<seriesInfo name="RFC" value="2104" />
</reference>
<reference anchor="RFC.4082">
<front>
<title>Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction</title>
<author initials="A" surname="Perrig" fullname="A Perrig">
<organization />
</author>
<author initials="R" surname="Canetti" fullname="R Canetti">
<organization />
</author>
<author initials="J D" surname="Tygar" fullname="J D Tygar">
<organization />
</author>
<author initials="B" surname="Briscoe" fullname="B Briscoe">
<organization />
</author>
<date month="June" year="2005" />
</front>
<seriesInfo name="RFC" value="4082" />
</reference>
<reference anchor="MSEC-TESLA">
<front>
<title>Use of TESLA in the ALC and NORM Protocols</title>
<author initials="V." surname="Roca" fullname="V. Roca">
<organization/></author>
<author initials="A." surname="Francillon" fullname="A. Francillon">
<organization/></author>
<author initials="S." surname="Faurite" fullname="S. Faurite">
<organization/></author>
<date year="2009" month="October"/>
</front>
<seriesInfo name="" value="draft-ietf-msec-tesla-for-alc-norm-10.txt (work in progress)"/>
</reference>
<reference anchor="RMT-SIMPLE-AUTH">
<front>
<title>Simple Authentication Schemes for the ALC and NORM Protocols</title>
<author initials='V.' surname='Roca'> <organization /></author>
<date month="October" year="2009"/>
</front>
<seriesInfo name="" value="draft-ietf-rmt-simple-auth-for-alc-norm-02.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>If the recovered object was an FDT Instance with FDT Instance ID 'N', the receiver parses the payload of the
instance 'N' of FDT and updates its FDT database accordingly. The receiver identifies FDT Instances within a file
delivery session by the EXT_FDT header extension. Any object that is delivered using EXT_FDT header extension is
an FDT Instance, uniquely identified by the FDT Instance ID. Note that TOI '0' is exclusively reserved for FDT
delivery.</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 file with the given properties. The receiver also checks that
received content length matches with the description in the database. Optionally, if MD5 checksum has been used,
the receiver checks that calculated MD5 matches with 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:07:36 |