RMT T. Paila
Internet-Draft Nokia
Expires: December 10, 2003 M. Luby
Digital Fountain
R. Lehtonen
TeliaSonera
V. Roca
INRIA Rhone-Alpes
June 11, 2003
FLUTE - File Delivery over Unidirectional Transport
draft-ietf-rmt-flute-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 10, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
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.
Paila, et al. Expires December 10, 2003 [Page 1]
Internet-Draft FLUTE June 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . 4
3. File delivery . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 File delivery session . . . . . . . . . . . . . . . . . . . 5
3.2 File Delivery Table . . . . . . . . . . . . . . . . . . . . 6
3.3 Dynamics of FDT Instances within file delivery session . . . 7
3.4 Structure of FDT Instance . . . . . . . . . . . . . . . . . 9
3.4.1 Format of FDT Instance Header . . . . . . . . . . . . . . . 10
3.4.2 Syntax of FDT Instance Payload . . . . . . . . . . . . . . . 10
3.5 Multiplexing of files within a file delivery session . . . . 12
4. Channels, congestion control and timing . . . . . . . . . . 13
5. Delivering FEC Object Transmission Information . . . . . . . 14
5.1 Use of EXT_FTI for delivery of FEC Object Transmission
Information . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1 General EXT_FTI format . . . . . . . . . . . . . . . . . . . 14
5.1.2 FEC Encoding ID Specific Formats for EXT_FTI . . . . . . . . 15
5.2 Use of FDT for delivery of FEC Object Transmission
Information . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Describing file delivery sessions . . . . . . . . . . . . . 18
7. Using SDP for describing file delivery sessions
(informative) . . . . . . . . . . . . . . . . . . . . . . . 19
8. Receiver operation (informative) . . . . . . . . . . . . . . 20
9. Examples (informative) . . . . . . . . . . . . . . . . . . . 22
9.1 Example of delivery session description using SDP . . . . . 22
9.2 Example of FDT Instace Payload . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
Normative References . . . . . . . . . . . . . . . . . . . . 27
Informative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . 30
Paila, et al. Expires December 10, 2003 [Page 2]
Internet-Draft FLUTE June 2003
1. Introduction
This document defines FLUTE, a protocol for unidirectional delivery
of files over the Internet. The specification builds on Asynchronous
Layered Coding (ALC), version 1 [3], 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 do the objects actually represent. This document specifies
a technique called FLUTE - a mechanism for signalling 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.
This specification answers the following questions:
* How does an ALC session represent a file delivery session?
* How can the properties of delivered files be signaled in-band
within the file delivery session?
* How to describe the file delivery session, its transport details
and its schedule in a general case, and using known session
description techniques?
* What is the internal structure of file delivery sessions wherein
several files can be delivered within a single session?
This specification is structured as follows. Chapter 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
transport objects within a file delivery session. Chapter 4
describes the use of congestion control and channels with FLUTE.
Chapter 5 defines how the FEC Object Transmission Information is to
be delivered within a file delivery session. Chapter 6 defines the
required parameters for describing file delivery sessions in a
general case. Chapter 7 defines the way to use SDP [8] for the
purpose of describing file delivery sessions. Chapter 8 gives
examples of both describing the file delivery sessions as well as
File Delivery Table. Chapter 9 describes an envisioned receiver
operation for the receiver of the file delivery session. Due to
their exemplifying nature, chapters 7, 8 and 9 are informative.
Last, chapter 10 outlines security considerations regarding file
delivery with FLUTE.
Paila, et al. Expires December 10, 2003 [Page 3]
Internet-Draft FLUTE June 2003
2. Conventions used in this document
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 [2].
Paila, et al. Expires December 10, 2003 [Page 4]
Internet-Draft FLUTE June 2003
3. File delivery
Asynchronous Layered Coding 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.
In this specification the above-mentioned arbitrary binary objects
are files. The core of this specification is to define how the
properties of the files are carried in-band together with the
delivered files.
As an example, let us consider a file referred by "www.ex.com/docs/
file.txt". Using the example, the following properties describe the
properties that need to be conveyed by the file delivery protocol.
* Location of the file, expressed as either absolute or relative
URL. In the above example: "www.ex.com/docs/file.txt"
* File name (usually, this can be concluded from the URL). In the
above example: "file.txt"
* 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"
* File size, expressed as bytes. In the above example (imaginary):
"5200"
* Content encoding of the file, within transport. In the above
example, the file could be encoded using ZLIB [9].
* Security properties of the file such as digital signatures,
message digestives, etc.
3.1 File delivery session
ALC is a protocol instantiation of Layered Coding Transport building
block (LCT) [4]. Thus ALC inherits the session concept of LCT. In
this document we will use concept ALC/LCT session to collectively
denote the interchangeable terms ALC session and LCT session.
An ALC/LCT session consists of a set of logically grouped ALC/LCT
channels associated with a single sender carrying 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
Paila, et al. Expires December 10, 2003 [Page 5]
Internet-Draft FLUTE June 2003
the data packets sent to the channel by the sender, and a receiver
leaves a channel to stop receiving data packets from the channel.
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
the receiver is joined to multiple sessions. In case multiple
objects are carried within a session another field within the ALC/LCT
header, the Transport Object Identifier (TOI), identifies from which
object within the session the data in the packet was generated. Note
that each object is associated with a unique TOI within the scope of
a session.
When FLUTE is used for file delivery over ALC the following rules
apply:
* The ALC/LCT session will be called file delivery session.
* ALC/LCT concept of 'transport object' denotes either a 'file' or a
'File Delevery Table Instance (section 3.2)'
* TOI field MUST be used in ALC/LCT packets.
* TOI value '0' is reserved for delivery of File Delivery Table
* Each file in a file delivery session MUST be associated with a TOI
(>0) in the scope of that session.
3.2 File Delivery Table
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. Such attributes are for example the
following.
Attributes related to the delivery of file:
- TOI value that represents the file
- FEC Encoding ID, FEC Instance ID
- FEC Object Transmission Information
Paila, et al. Expires December 10, 2003 [Page 6]
Internet-Draft FLUTE June 2003
- Aggregate rate of sending packets to all channels
Attributes related to the file itself:
- Location of file
- Name of file
- MIME media type of file
- Size of file
- Encoding of file
Logically, the FDT is a set of file description entries. Each file
description entry is identified by a unique identifier in the a given
session. In FLUTE, the identifier is the URL (location) of the file.
Each file description entry consequently contains one or more
descriptors that map the above-mentioned attributes to the identified
file. At minimum the mapping to TOI value has to be given.
Each file delivery session MUST have an FDT that is local to the
given session. The FDT SHOULD provide mapping for every TOI
appearing within the session. Handling of unmapped TOIs (those that
are not resolved by the FDT) is out of scope of this specification.
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 either equal, a subset
or a superset of any other FDT Instance. In minimum the FDT Instance
contains a single file description entry. In maximum the FDT
Instance contains the complete FDT of the file delivery session.
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.
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.
3.3 Dynamics of FDT Instances within file delivery session
Paila, et al. Expires December 10, 2003 [Page 7]
Internet-Draft FLUTE June 2003
The following rules define the dynamics of the FDT Instances within a
file delivery session:
* Within a file delivery session, the complete FDT MUST be sent at
least once. The complete FDT is defined as an FDT that has file
description entry for every file sent within the file delivery
session. In minimum, each file description entry contains the
mapping to TOI.
* The complete FDT MAY be sent either in one or more FDT Instances.
* An FDT Instance MAY appear in any part of the file delivery
session and even multiplexed with other files or other FDT
Instances.
* 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.
* FDT Instance is identified by the use of a new fixed length LCT
Header Extension EXT_FDT (defined later in this chapter). Each
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.
* It is RECOMMENDED that 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.
* Within a file delivery session, any TOI MUST NOT be defined more
than once. An example: previous FDT Instance 0 defines TOI of
value '3'. Now, subsequent FDT Instances can either keep TOI '3'
unmodified on the table, or not include it. In the latter case
the receiver interpretation of such a situation is specific to
implementation and therefore is left out of scope of this
specification.
* An FDT Instance is valid until its expiration time. The expiry
time is expressed within the FDT Instance payload as a 32 bit
Network Time Protocol (NTP) time value in seconds.
* The receiver behaviour upon expiration of the FDT Instance is out
of scope of this specification.
* A sender MUST use an expiry time in the future upon creation of an
FDT Instance.
Paila, et al. Expires December 10, 2003 [Page 8]
Internet-Draft FLUTE June 2003
* 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.
3.4 Structure of FDT Instance
The FDT Instance consist of two parts: FDT Instance Header and FDT
Instance Payload. The FDT Instance Header is a new fixed length LCT
Header extension (EXT_FDT). It 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.
After LCT extension headers there is FEC Payload ID, which is
followed by the FDT Instance Payload. It contains the actual mapping
table with file description entries. The FDT Instance Payload MAY
span over several ALC packets. The FDT Instance Header is carried in
each ALC packet carrying FDT Instance. The FDT Instance Header is
identical for all the ALC/LCT packets carrying parts of a particular
FDT Instance.
The overall format of ALC/LCT packets carrying FDT Instance is
depicted in the Figure 1 below.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP header |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Default LCT header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCT header extensions (EXT_FDT, EXT_FTI, etc.) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) of FDT Instance Payload |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Overall FDT Packet
Paila, et al. Expires December 10, 2003 [Page 9]
Internet-Draft FLUTE June 2003
3.4.1 Format of FDT Instance Header
FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI specific
LCT header extension [4]. 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 | FDT Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FDT Instance ID, 24 bits:
For each file delivery session the numbering of FDT Instances starts
from '0' and is incremented by exactly one for each subsequent FDT
Instance. After reaching the maximum value (2^24-1), the numbering
starts again from '0'. When wraparound from 2^24-1 to 0 occurs, 0 is
considered higher than 2^24-1. Receiver handling of wraparound and
other special situations (for example, missing FDT Instance IDs
resulting in longer increments than one) is left out of this
specification to individual implementations of FLUTE.
3.4.2 Syntax of FDT Instance Payload
FDT Instance Payload contains file description entries that provide
the mapping functionality described in 3.2 above.
FDT Instance Payload is an XML structure that has a single root
element "FDT-Payload". The "FDT-Payload" element MUST contain
"Expires" attribute, which tells the expiry time of the FDT Instance
Payload. For each file to be declared in the given FDT Instance
there is a single file description entry in the FDT Instance Payload.
Each entry is represented by element "File" which is a child element
of the FDT Payload 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. 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 URL as defined in [6].
In addition to mandatory attributes, the "File" entity MAY contain
other attributes of which the following are specifically pointed out.
Paila, et al. Expires December 10, 2003 [Page 10]
Internet-Draft FLUTE June 2003
* If the MIME type of the file is described, attribute
"Content-Type" MUST be used for the purpose as defined in [6].
* If the length of the file is described, attribute "Content-Length"
MUST be used for the purpose as defined in [6].
* If the encoding scheme of the file is described, attribute
"Content-Encoding" MUST be used for the purpose as defined in [6].
* If the MD5 message digest of the file is described, attribute
"Content-MD5" MUST be used for the purpose as defined in [6].
The following specifies the XML Schema for FDT Instance Payload:
<?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-Payload">
<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:nonNegativeInteger" use="required"/>
<xs:attribute name="Content-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:anyAttribute processContents="skip" />
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="Expires" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
Any XML document that conforms with the above XML Schema is a valid
FDT. This way FDT provides extensibility 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, those MUST be placed within the attributes of the
element "File". It is RECOMMENDED that the new descriptors applied
in the FDT are in the format of MIME fields and are either defined in
HTTP/1.1 specification [6] or otherwise well-known.
Paila, et al. Expires December 10, 2003 [Page 11]
Internet-Draft FLUTE June 2003
3.5 Multiplexing of files within a file delivery session
The delivered files appear as objects (identified with TOIs) within
the file delivery session. All the objects, including the FDT
Instances, MAY be multiplexed in any order and in parallel with each
other.
Especially multiple FDT Instances MAY be delivered during the session
in a particular TOI. 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 the FDT Instances MAY be multiplexed packetwise. In that
case, the FDT Instances are uniquely identified by their EXT_FDT
headers.
Paila, et al. Expires December 10, 2003 [Page 12]
Internet-Draft FLUTE June 2003
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, like 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, like 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 object must complete 'prior' to the second one, it is
RECOMMENDED that only a single channel is used for the file delivery
session.
Paila, et al. Expires December 10, 2003 [Page 13]
Internet-Draft FLUTE June 2003
5. Delivering FEC Object Transmission Information
FLUTE inherits the use of FEC building block [5] 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 chapter, two methods are specified for FLUTE for
this purpose: the use of ALC specific LCT extension header EXT_FTI
[3], 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
either method MAY be applied: the use of EXT_FTI and the use of 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.
2. FEC Object Transmission Information that is available in the FDT.
3. FEC Object Transmission Information that is available out of
band.
5.1 Use of EXT_FTI for delivery of FEC Object Transmission Information
As specified in [3], the EXT_FTI header extension is intended to
carry in band the FEC Object Transmission Information for an object.
It is left up to individual implementations to decide how frequently
and in which ALC packets the EXT_FTI header extension occurs.
The ALC specification does not define the format or the processing of
the EXT_FTI header extension. The following sections specify EXT_FTI
when used in FLUTE.
In FLUTE, the FEC Encoding ID (8 bits) is carried in the Codepoint
field of the ALC/LCT header.
5.1.1 General EXT_FTI format
The general EXT_FTI format specifies the structure and those
attributes of FEC Object Transmission Information that are applicable
to any FEC Encoding ID.
Paila, et al. Expires December 10, 2003 [Page 14]
Internet-Draft FLUTE June 2003
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 = 64 | HEL | FEC Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Length |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Encoding ID Specific Format |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header Extension Type (HET), 8 bits:
64 as defined in [3]
Header Extension Length (HEL), 8 bits:
The length of the whole Header Extension field, expressed in
multiples of 32-bit words. This length includes the FEC Encoding ID
Specific Format part.
FEC Instance ID, optional, 16 bits:
This field is used for FEC Instance ID. It is only present if the
value of FEC Encoding ID is in the range of 128-255. When the value
of FEC Encoding ID is in the range of 0-127, this field is set to 0.
Object Length, 64 bits:
As specified in [3]. The length of the object in bytes.
FEC Encoding ID Specific Format:
Different FEC encoding schemes will need different sets of encoding
parameters. Thus, the structure of this field depends on FEC
Encoding ID. The next sections specify structure of this field for
FEC Encoding ID numbers 0, 128, 129 and 130.
5.1.2 FEC Encoding ID Specific Formats for EXT_FTI
All of the FEC Encoding Ids have an Encoding Symbol Length associated
with them. In all cases the Encoding Symbol Length can be deduced
from the length of the payload of the packet. Encoding Symbol
Lengths for the same TOI MUST all be the same length.
5.1.2.1 FEC Encoding ID 0
Compact No-Code FEC (Fully-Specified) [7]. The FEC Encoding ID
Paila, et al. Expires December 10, 2003 [Page 15]
Internet-Draft FLUTE June 2003
Specific Format of EXT_FTI is defined as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Block Length, 32 bits:
For each source block of the object, the length of the source block
in bytes.
5.1.2.2 FEC Encoding ID 128
Small Block, Large Block and Expandable FEC (Under-Specified). The
FEC Encoding ID Specific Format of EXT_FTI is defined as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Source Blocks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of Source Blocks, 32 bits:
The number of source blocks that the object is partitioned into.
Source Block Length, 16 bits:
Length of source block in bytes
5.1.2.3 FEC Encoding ID 129
Small Block Systematic FEC (Under-Specified). The FEC Encoding ID
Specific Format of EXT_FTI is defined as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Number of Encoding Symbols |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Maximum Number of Encoding Symbols, 32 bits:
Maximum number of encoding symbols that can be generated for a source
Paila, et al. Expires December 10, 2003 [Page 16]
Internet-Draft FLUTE June 2003
block.
5.1.2.4 FEC Encoding ID 130
Compact FEC (Under-Specified) [7]. The FEC Encoding ID Specific
Format of EXT_FTI is defined as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Source Blocks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of Source Blocks, 32 bits:
The number of source blocks that the object is partitioned into.
Source Block Length, 32 bits:
For every source block of the object, the length of the source block
in bytes.
5.2 Use of FDT for delivery of FEC Object Transmission Information
The receiver of file delivery session MAY support delivery of FEC
Object Transmission Information using FDT. In that case the FEC
Object Transmission Information MUST be expressed with one or more
attributes within the "File" element of the FDT structure. The names
of attributes and their specific formats to describe the FEC OTI in
the FDT is out of the scope of this document.
Paila, et al. Expires December 10, 2003 [Page 17]
Internet-Draft FLUTE June 2003
6. Describing file delivery sessions
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 on the receiver operation falls into the scope
of this specification. According to [3], the parameters of transport
that the receiver needs to know are:
* The sender IP address;
* The number of channels in the session;
* The destination IP address and port number for each channel in the
session;
* The Transport Session Identifier (TSI) of the session;
* An indication of whether or not the session carries packets for
more than one object;
Optionally, the following parameters MAY be associated with the
session:
* The start time and end time of the session;
* FEC Encoding ID and FEC Instance ID when the default FEC Encoding
ID 0 is not used for the delivery of FDT.
* Compression format if optional compression of FDT Instance Payload
is used.
* Some information that tells receiver, in the first place, that the
session contains files that are of interest
How the receiver acquires the above-mentioned parameters is out of
scope of this document. The specification, in particular, does not
mandate or exclude any mechanism. The description can be conveyed to
the receiver via techniques such as Session Announcement Protocol
[10], email, accessing URL, manual configuration, etc.
Paila, et al. Expires December 10, 2003 [Page 18]
Internet-Draft FLUTE June 2003
7. Using SDP for describing file delivery sessions (informative)
The way in which to describe file delivery session (to express the
parameters defined in section 5) using existing description
techniques is important. However, such definition falls out of the
scope of this specification. Therefore, in the following we give an
informative example how the file delivery session can be described
using the Session Description Protocol (SDP)[8]
File delivery session is described using 'Media description'
component of SDP as follows:
* Media type is 'application'
* Port number corresponds to the UDP port in which the file delivery
session is to be transmitted.
* Transport protocol is 'FLUTE'.
* Media format is '0'
* If not defined on session level, the destination IP address is
contained in the 'c=' field of the media description.
In addition, the file delivery session is described on session level
as follows:
* The source IP address is expressed using "source-filter" attribute
as described in [13].
* If there is only one channel in use in the file delivery session,
the destination (or group) address can appear in two ways. It is
either contained in the 'c=' field as a session level definition,
or in the 'c=' field of the media description.
* Session level timing field 't=' defines the start and end time of
the file delivery session. For repetition, 'r=' field MAY be
used.
* A special attribute 'a=flute-tsi:' is used on the session level.
This attribute contains the ALC/LCT Transport Session Identifier
associated with the file delivery session.
* A special attribute 'a=flute-ch:' is used on the session level to
describe how many channels belong to this file delivery session.
Paila, et al. Expires December 10, 2003 [Page 19]
Internet-Draft FLUTE June 2003
8. Receiver operation (informative)
This chapter 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.
1. 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.
2. 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.
3. 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.
4. 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.
5. Receiver recovers a file. A file can be recovered when an
appropriate set of packets containing encoding symbols for the
file have been received and the file can be recovered. 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.
6. If the recovered file 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 file 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.
7. If a file other than FDT was recovered the receiver looks up its
FDT database and assigns file with the properties described in the
database. The receiver also checks that received content length
matches with the description in the database. Optionally, if MD5
Paila, et al. Expires December 10, 2003 [Page 20]
Internet-Draft FLUTE June 2003
checksum has been used, the receiver checks that calculated MD5
matches with the description in the FDT database.
8. The actions receiver takes with imperfectly received files
(missing data, mismatching digestive, etc.) is outside the scope
of this specification. A possible behavior is to wait until an
FDT instance is received that includes the missing properties.
9. If the file delivery session end time has not been reached go
back to 3. Otherwise end.
Paila, et al. Expires December 10, 2003 [Page 21]
Internet-Draft FLUTE June 2003
9. Examples (informative)
This section provides an example on how to describe the file delivery
session using SDP and an example on FDT Instance Payload.
9.1 Example of delivery session description using SDP
The following example defines that there is a file delivery session
available in the time between 2873397496 and 2873404696, specified as
NTP time values in seconds. The source address of file delivery
session is 2001:210:1:2:240:96FF:FE25:8EC9 and the value for TSI is
3. The delivery uses two channels with IPv6 multicast addresses
FF1E:03AD::7F2E:172A:1E24 and FF1E:03AD::7F2E:172A:1E30. The UDP
ports are 12345 and 12346, respectively.
v=0
o=user123 2890844526 2890842807 IN IP6 2201:056D::112E:144A:1E24
s=File delivery session example
i=More information
t=2873397496 2873404696
a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9
a=flute-tsi:3
a=flute-ch:2
m=application 12345 FLUTE 0
c=IN IP6 FF1E:03AD::7F2E:172A:1E24/127
m=application 12346 FLUTE 0
c=IN IP6 FF1E:03AD::7F2E:172A:1E30/127
9.2 Example of FDT Instace Payload
<?xml version="1.0" encoding="UTF-8"?>
<FDT-Payload xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fl="http://www.example.com/flute" xsi:schemaLocation="http://www.example.com/flute fdt-6a.xsd"
Expires="2890842807">
<File
Content-Location=www.example.com/menu/tracklist.html
TOI="1"
Content-Type="text/html"/>
<File
Content-Location=www.example.com/tracks/track1.mp3
TOI="2"
Content-Length="6100"
Content-Type="audio/mp3"
Content-Encoding="gzip"
Content-MD5="Eth76GlkJU45sghK"
Some-Private-Extension-Tag="abc123"/>
Paila, et al. Expires December 10, 2003 [Page 22]
Internet-Draft FLUTE June 2003
</FDT-Payload>
Paila, et al. Expires December 10, 2003 [Page 23]
Internet-Draft FLUTE June 2003
10. Security Considerations
There is a risk of forged file delivery sessions. A malicious
attacker may spoof file delivery (ALC/LCT) packets in order to
initiate an attack. The attacker may have several objectives he or
she wishes to achieve, like Denial of Service (DoS). The following
are the most obvious risks, however not exhaustive.
The attacker can focus on the FDT information, sending forged packets
with erroneous FDT-Payload fields. Many attacks can follow this
approach. For instance a malicious attacker may alter the
Content-Location field of TOI 'n', to make it point to a system file
or a user configuration file. Then, TOI 'n' can carry a Trojan horse
or some other type of virus. Another example is generating a bad
Content-MD5 sum, leading receivers to reject the associated file that
will be declared corrupted. The Content-Encoding can also be
modified, which also prevents the receivers to correctly handle the
associated file.
These examples show that the FDT information is critical to the FLUTE
delivery service. It is therefore highly RECOMMENDED that the FDT
information be protected by the appropriate security measures. For
instance TESLA [12] can be used for authenticating the FDT source,
along with the other packets exchanged during the ALC/LCT session.
In some cases a group authentication service can be sufficient. In
that case, simple and efficient cryptographic transforms can then be
used [11]. The FDT content may also be digitally signed, which
provides both source authentication and packet integrity. This is
feasible if the FDT packet rate is kept sufficiently low (generating/
verifying digital signatures are computationally demanding tasks).
In that case, the number of signature verifications at a receiver
should be rate limited in order to prevent DoS attacks consisting in
sending a high number of forged FDT packets. Finally it is
RECOMMENDED that the FLUTE delivery service does not have write
access to the system or any other critical areas.
An attacker can also eavesdrop on the FLUTE session. Packets
containing the FDT information are critical from that point of view
since they contain information on the session content. When this is
an issue it is RECOMMENDED that the FDT packets be encrypted (as well
as the data packets) using a confidentiality service. The MSEC IETF
Working Group defines security transforms, Group Key Management and
Group Security Associations building blocks that can be used to that
purpose.
A difficulty is the unidirectional feature of FLUTE. Many protocols
providing application-level security are based on bidirectional
communications. The application of these security protocols in case
Paila, et al. Expires December 10, 2003 [Page 24]
Internet-Draft FLUTE June 2003
of strictly unidirectional links is not considered in the present
document.
In addition to the attacks on the FDT information, FLUTE is subject
to attacks on the ALC/LCT session itself. Therefore, the security
considerations of [3] and [4] also apply to FLUTE.
Paila, et al. Expires December 10, 2003 [Page 25]
Internet-Draft FLUTE June 2003
11. Acknowledgements
The following persons have contributed to this specification: Vincent
Roca, Rod Walsh, Juha-Pekka Luoma, Esa Jalonen, Sami Peltotalo and
Jani Peltotalo. The authors would like to thank all the contributors
for their valuable work in reviewing and providing feedback regarding
this specification.
Paila, et al. Expires December 10, 2003 [Page 26]
Internet-Draft FLUTE June 2003
Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", RFC
2026, BCP 9, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[3] Luby, M., Gemmel, J., Vicisano, L., Rizzo, L. and J. Crowcroft,
"Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC
3450, December 2002.
[4] Luby, M., Gemmel, J., Vicisano, L., Rizzo, L. and J. Crowcroft,
"Layered Coding Transport (LCT) Building Block", RFC 3451,
December 2002.
[5] Luby, M., Gemmel, J., Vicisano, L., Rizzo, L., Crowcroft, J. and
M. Handley, "Forward Error Correction (FEC) Building Block", RFC
3452, December 2002.
[6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[7] Luby, M. and L. Vicisano, "Compact Forward Error Correction
(FEC) Schemes", draft-ietf-rmt-bb-fec-supp-compact-01 (work in
progress), May 2003.
Paila, et al. Expires December 10, 2003 [Page 27]
Internet-Draft FLUTE June 2003
Informative References
[8] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, March 1998.
[9] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[10] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[11] Hardjono, T. and B. Weis, "The Multicast Security
Architecture", draft-ietf-msec-arch-01 (work in progress), May
2003.
[12] Perrig, A., Canetti, R., Song, D., Tygar, D. and B. Briscoe,
"TESLA: Multicast Source Authentication Transform
Introduction", draft-ietf-msec-tesla-intro-01 (work in
progress), October 2002.
[13] Quinn, B. and R. Finlayson, "Session Description Protocol (SDP)
Source Filters", draft-ietf-mmusic-sdp-srcfilter-05 (work in
progress), May 2003.
Authors' Addresses
Toni Paila
Nokia
Itamerenkatu 11-13
Helsinki FIN-00180
Finland
EMail: toni.paila@nokia.com
Michael Luby
Digital Fountain
39141 Civic Center Dr.
Suite 300
Fremont, CA 94538
USA
EMail: luby@digitalfountain.com
Paila, et al. Expires December 10, 2003 [Page 28]
Internet-Draft FLUTE June 2003
Rami Lehtonen
TeliaSonera
Hatanpaan valtatie 18
Tampere FIN-33100
Finland
EMail: rami.lehtonen@teliasonera.com
Vincent Roca
INRIA Rhone-Alpes
655, av. de l'Europe
Montbonnot
St Ismier cedex 38334
France
EMail: vincent.roca@inrialpes.fr
Paila, et al. Expires December 10, 2003 [Page 29]
Internet-Draft FLUTE June 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Paila, et al. Expires December 10, 2003 [Page 30]
