32 bit data field. The value of the data field represents the 32
most significant bits of a 64 bit Network Time Protocol (NTP) [5]
time value. These 32 bits provide an unsigned integer
representing the time in seconds relative to 0 hours 1 January
1900. Handling of wraparound of the 32 bit time is outside the
scope of NTP and FLUTE.
* The receiver SHOULD NOT use a received FDT Instance to interpret
packets received beyond the expiration time of the FDT Instance.
* A sender MUST use an expiry time in the future upon creation of an
FDT Instance relative to its Sender Current Time (SCT).
* Any FEC Encoding ID MAY be used for the sending of FDT Instances.
The default is to use FEC Encoding ID 0 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.)
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.
3.4. Structure of FDT Instance packets
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.
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.
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 [2], all ALC/LCT packets are sent
using UDP.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Default LCT header (with TOI = 0) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCT header extensions (EXT_FDT, EXT_FTI, etc.) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) for FDT Instance |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Overall FDT Packet
3.4.1. Format of FDT Instance Header
FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI specific
LCT header extension [3]. The Header Extension Type (HET) for the
extension is 192. Its format is defined below:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version of FLUTE (V), 4 bits:
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’.
FDT Instance ID, 20 bits:
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 again
from ’0’. When wraparound from 2^20-1 to 0 occurs, 0 is considered
higher than 2^20-1. 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. It would be reasonable for
FLUTE Senders to only construct and deliver FDT Instances with
wraparound IDs after the previous FDT Instance using the same ID has
expired. However, 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.
3.4.2. Syntax of FDT Instance
The FDT Instance contains file description entries that provide the
mapping functionality described in 3.2 above.
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 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). For example, this
may be used to provide a complete list of files in an entire FLUTE
session (a "complete FDT").
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.
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.
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 [6].
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.
* Where the MIME type is described, the attribute "Content-Type"
MUST be used for the purpose as defined in [6].
* Where the length is described, the attribute "Content-Length" MUST
be used for the purpose as defined in [6]. 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.
* Where the content encoding scheme is described, the attribute
"Content-Encoding" MUST be used for the purpose as defined in [6].
* Where the MD5 message digest is described, the attribute
"Content-MD5" MUST be used for the purpose as defined in [6].
* The FEC Object Transmission Information attributes as described in
section 5.2.
The following specifies the XML Schema [8][9] for FDT Instance:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:fl="http://www.example.com/flute"
elementFormDefault:xs="qualified"
targetNamespace:xs="http://www.example.com/flute">
<xs:element name="FDT-Instance">
<xs:complexType>
<xs:sequence>
<xs:element name="File" maxOccurs="unbounded">
<xs:complexType>
<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:unsignedLong"
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:anyAttribute processContents="skip"/>
</xs:complexType>
</xs:element>
</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:unsignedLong"
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:anyAttribute processContents="skip"/>
</xs:complexType>
</xs:element>
</xs:schema>
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.).
In case the basic FDT XML Schema is extended in terms of new
descriptors, for attributes applying to a single file, those MUST be
placed within the attributes of the element "File". For attributes
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 descriptors applied in the FDT are in the format of MIME
fields and are either defined in the HTTP/1.1 specification [6] or
another well-known specification.
3.4.3. Content Encoding of FDT Instance
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 [3]. 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:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Content Encoding Algorithm (CENC), 8 bits:
This field signals the content encoding algorithm used in the FDT
Instance payload. The definition of this field is outside the scope
of this specification. Applicable content encoding algorithms
include, for example, ZLIB [10], DEFLATE [16] and GZIP [17].
Reserved, 16 bits:
This field MUST be set to all ’0’.
3.5. Multiplexing of files within a file delivery session
The delivered files are carried as transport 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.
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.
4. Channels, congestion control and timing
ALC/LCT has a concept of channels and congestion control. There are
four scenarios FLUTE is envisioned to be applied.
(a) Use a single channel and a single-rate congestion control
protocol.
(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.
(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.
(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.
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.
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 transport object must complete ’prior’ to the second one, it is
RECOMMENDED that only a single channel is used for the file delivery
session.
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:
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 ok 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 ok to put all the
packets for an FDT Instance into the higher layers that only high
rate receivers will receive.
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 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.
5. Delivering FEC Object Transmission Information
FLUTE inherits the use of FEC building block [4] 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. In this section, two methods are specified for FLUTE for
this purpose: the use of ALC specific LCT extension header EXT_FTI
[2] and the use of FDT.
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.
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). Section 5.1 describes the required
FEC Object Transmission Information that MUST be delivered to
receivers for various FEC Encoding IDs. In addition, it describes
the delivery using EXT_FTI. Section 5.2 describes the delivery using
FDT.
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).
1. FEC Object Transmission Information that is available in EXT_FTI.