| Reliable Multicast Transport (RMT) | T. Paila |
| Internet-Draft | R. Walsh |
| Obsoletes: 3926 (if approved) | Nokia |
| Intended status: Standards Track | M. Luby |
| Expires: August 08, 2011 | Qualcomm, Inc. |
| V. Roca | |
| INRIA | |
| R. Lehtonen | |
| TeliaSonera | |
| February 04, 2011 |
FLUTE - File Delivery over Unidirectional Transport
draft-ietf-rmt-flute-revised-12
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 08, 2011.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
This document defines FLUTE version 2, a protocol for unidirectional delivery of files over the Internet. This specification may not be backwards compatible with the previous experimental version defined in [RFC3926]. The specification builds on Asynchronous Layered Coding (ALC), version 1 [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.
This document defines a specific transport application of ALC, adding the following specifications:
This specification is structured as follows. Section 3 begins by defining the concept of the file delivery session. Following that it introduces the File Delivery Table that forms the core part of this specification. Further, it discusses multiplexing issues of transmission objects within a file delivery session. Section 4 describes the use of congestion control and channels with FLUTE. Section 5 defines how the Forward Error Correction (FEC) Object Transmission Information is to be delivered within a file delivery session. Section 6 defines the required parameters for describing file delivery sessions in a general case. Section 7 outlines security considerations regarding file delivery with FLUTE. Last, there are two informative appendices. Appendix A describes an envisioned receiver operation for the receiver of the file delivery session. Readers who want to see a simple example of FLUTE in operation should refer to Appendix A right away. Appendix B gives an example of a File Delivery Table.
This specification contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC2357.
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.
The differences between RFC3926 and this document are listed in Section 11.
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 [RFC.SDP] files which enable user applications to access multimedia sessions.
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.
All of the environmental requirements and considerations that apply to the RMT Building Blocks used by FLUTE shall also apply to FLUTE. These are the ALC protocol instantiation [ID.ALC-revised], the Layered Coding Transport (LCT) Building Block [RFC5651] and the FEC Building Block [RFC5052].
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.
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) [RFC.ASM] and the Source-Specific Multicast (SSM) [PAPER.SSM].
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.
FLUTE congestion control protocols depend on the ability of a receiver to change multicast subscriptions between multicast groups supporting different rates and/or layered codings. If the network does not support this, then the FLUTE congestion control protocols may not be amenable to these networks
FLUTE can also be used for point-to-point (unicast) communications. At a minimum, implementations of ALC MUST support the Wave and Equation Based Rate Control (WEBRC) [RFC.3738] multiple rate congestion control scheme [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 that is outside the scope of the present document.
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.
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 [RFC.2119].
The terms "object" and "transmission object" are consistent with the definitions in ALC [ID.ALC-revised] and LCT [RFC.LCT]. The terms "file" and "source object" are pseudonyms for "object".
Asynchronous Layered Coding [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.
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.
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.
For each unique file, FLUTE encodes the attributes listed above and other attributes as children of an XML file element. A table of XML file elements is transmitted as a special file called a 'File Delivery Table' (FDT) which is further described in the next subsection and in section 3.2
ALC is a protocol instantiation of Layered Coding Transport building block (LCT) [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.
An ALC/LCT session consists of a set of logically grouped ALC/LCT channels associated with a single sender sending ALC/LCT packets for one or more objects. An ALC/LCT channel is defined by the combination of a sender and an address associated with the channel by the sender. A receiver joins a channel to start receiving the data packets sent to the channel by the sender, and a receiver leaves a channel to stop receiving data packets from the channel.
One of the fields carried in the ALC/LCT header is the Transport Session Identifier (TSI). The (source IP address, TSI) pair uniquely identifies a session. Note that the TSI is scoped by the IP address, so the same TSI may be used by several source IP addresses at once. Thus, the receiver uses the (source IP address, TSI) pair from each packet to uniquely identify the session sending each packet. When a session carries multiple objects, the Transmission Object Identifier (TOI) field within the ALC/LCT header names the object used to generate each packet. Note that each object is associated with a unique TOI within the scope of a session.
A FLUTE session consistent with this specification MUST use FLUTE version 2 as specified in this document. Thus, all sessions consistent with this specification MUST set the FLUTE version to 2. The FLUTE version is carried within the EXT_FDT extension header (defined in section 3.4.1) in the ALC/LCT layer. A FLUTE session consistent with this specification MUST use ALC version 1 as specified in RFC 5775, and LCT version 1 as specified in RFC 5651.
If multiple FLUTE sessions are sent to a channel then receivers MUST determine the FLUTE protocol version, based on version fields and the (source IP address, TSI) carried in the ALC/LCT header of the packet. Note that when a receiver first begins receiving packets, it MAY NOT know the FLUTE protocol version, as not every LCT packet carries the EXT_FDT header (containing the FLUTE protocol version.) A new receiver MAY keep an open binding in the LCT protocol layer between the TSI and the FLUTE protocol version, until the EXT_FDT header arrives. Alternately, a new receiver MAY discover a binding between TSI and FLUTE protocol version via a session discovery protocol that is out of scope in this document.
If the sender is not assigned a permanent IP address accessible to receivers, then packets that can be received by receivers contain a temporary IP address. In this case 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. In this case the TSI is scoped by the temporary IP address assigned by the NAT. As another example, the sender may send its original packets using IPv6, but some portions of the network may not be IPv6 capable. Thus, there may be an IPv6 to IPv4 translator that changes the IP address of the packets to a different IPv4 address. In this case, receivers in the IPv4 portion of the network will receive packets containing the IPv4 address, and thus the TSI for them is scoped by the IPv4 address. How the IP address of the sender to be used to scope the session by receivers is delivered to receivers, whether it is a permanent IP address or a temporary IP address, is outside the scope of this document.
When FLUTE is used for file delivery over ALC the following rules apply:
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.
Attributes related to the delivery of file:
Attributes related to the file itself:
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.
Logically, the FDT is a set of file description entries for files to be delivered in the session. Each file description entry MUST include the TOI for the file that it describes and the URI identifying the file. The TOI carried in each file description entry is how FLUTE names the ALC/LCT data packets used for delivery of the file. Each file description entry may also contain one or more descriptors that map the above-mentioned attributes to the file.
Each file delivery session MUST have an FDT that is local to the given session. The FDT MUST provide a file description entry mapped to a TOI for each file appearing within the session. An object that is delivered within the ALC session, but not described in the FDT, other than the FDT itself, is not considered a 'file' belonging to the file delivery session. Handling of these unmapped TOIs (Non-zero TOIs 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 equal to, a subset of, a superset of, overlap with or complement any other FDT Instance. A certain FDT Instance may be repeated multiple times during a session, even after subsequent FDT Instances (with higher FDT Instance ID numbers) have been transmitted. Each FDT Instance contains at least a single file description entry and at most the exhaustive set of file description entries of the files being delivered in the file delivery session.
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 the FDT database is an abstract concept, the structure and the maintenance of the FDT database are left to individual implementations and are thus out of scope of this specification.
The following rules define the dynamics of the FDT Instances within a file delivery session:
Generally, a receiver needs to receive an FDT Instance describing a file before it is able to recover the file itself. In this sense FDT Instances are of higher priority than files. Additionally, a FLUTE sender SHOULD assume receivers will not receive all packets pertaining to FDT Instances. The way FDT Instances are transmitted has a large impact on satisfying the recommendation above. When there is a single file transmitted in the session, one way to satisfy the recommendation above is to repeatedly transmit on a regular enough basis FDT Instances describing the file while the file is being transmitted. If an FDT Instance is longer than one packet payload in length, it is RECOMMENDED that an FEC code that provides protection against loss be used for delivering this FDT Instance. When there are multiple files in a session concurrently being transmitted to receivers, the way the FDT Instances are structured and transmitted also has a large impact. As an example, a way to satisfy the recommendation above is to transmit an FDT Instance that describes all files currently being transmitted, and to transmit this FDT Instance reliably, using the same techniques as explained for the case when there is a single file transmitted in a session. If instead the concurrently transmitted files are described in separate FDT Instances, another way to satisfy this recommendation is to transmit all the relevant FDT Instances reliably, using the same techniques as explained for the case when there is a single file transmitted in a session.
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.
Sometimes the various attributes associated with files that are to be delivered within the file delivery session are sent out-of-band (rather than in-band, within one or several FDT Instances). The details of how this is done are out of the scope of this document. However, it is still RECOMMENDED that any out-of-band transmission be managed in such a way that a receiver will be able to recover the attributes associated with a file with as much or greater reliability as the receiver is able to receive enough packets containing encoding symbols to recover the file. For example, the probability of a randomly chosen receiver being able to recover a given file can often be estimated based on a statistical model of reception conditions, the amount of data transmitted and the properties of any Forward Error Correction in use. The recommendation above suggests that mechanisms used for file attribute delivery should achieve higher a delivery probability than the file recovery probability.
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 FDT Instance is encoded for transmission, like any other object, using an FEC Scheme (which MAY be the Compact No-Code FEC Scheme) The LCT extension headers are followed by the FEC Payload ID, and finally the Encoding Symbols for the FDT Instance which contains one or more file description entries. A FDT Instance MAY span several ALC packets - the number of ALC packets is a function of the file attributes associated with the FDT Instance. The FDT Instance Header is carried in each ALC packet carrying the FDT Instance. The FDT Instance Header is identical for all ALC/LCT packets for a particular FDT Instance.
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 [ID.ALC-revised], 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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FLUTE Payload: Encoding Symbol(s)
~ (for FDT Instance in a FDT packet) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI specific LCT header extension [RFC.LCT]. 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 2. Hence in any ALC packet that carries FDT Instance and that belongs to the file delivery session as specified in this specification MUST set this field to '2'.
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 from the smallest FDT Instance value assigned to an expired FDT Instance. When wraparound from a greater FDT Instance ID value to a smaller FDT Instance ID value occurs, the smaller FDT Instance ID value is considered logically higher than the greater FDT Instance ID value. Senders SHOULD NOT re-use an FDT Instance ID value that is already in use for a non-expired FDT Instance. Sender behavior when all the FDT Instance IDs are used by non expired FEC Instances is outside the scope of this specification and left to individual implementations of FLUTE. Receipt of an FDT Instance that reuses an FDT Instance ID value that is currently used by a non expired FDT Instance SHOULD be considered as an error case. Receiver behavior in this case is outside the scope of this specification and left to individual implementations of FLUTE. Receivers MUST be ready to handle FDT Instance ID wraparound and situations where missing FDT Instance IDs result in increments larger than one.
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 expiration time of the FDT Instance. In addition, the "FDT-Instance" element MAY contain the "Complete" attribute (boolean), which, when TRUE, signals that this "FDT Instance" includes the set of "File" entries that exhausts both the set of files delivered so far and also the set of files to be delivered in the session. This implies that no new data will be provided in future FDT Instances within this session (i.e., that either FDT Instances with higher ID numbers will not be used or if they are used, will only provide identical file parameters to those already given in this and previous FDT Instances). The "Complete" attribute is therefore used to provide a complete list of files in an entire FLUTE session (a "complete FDT").
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 [RFC.HTTP11] which identifies the object to be delivered, for example a URI with the "http" or "file" URI scheme. The semantics for any two "File" elements declaring the same "Content-Location" but differing "TOI" is that the element appearing in the FDT Instance with the greater FDT Instance ID is considered to declare newer instance (e.g. version) of the same "File".
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.
The following specifies the XML Schema [XML-Schema-Part-1][XML-Schema-Part-2] for FDT Instance:
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
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 (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 [RFC.HTTP11] or another well-known specification.
The FDT Instance itself MAY be content encoded, for example compressed. This specification defines FDT Instance Content Encoding Header (EXT_CENC). EXT_CENC is a new fixed length LCT header extension [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:
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. This subsection reserves the Content Encoding Algorithm values 0, 1, 2 and 3 for null, ZLIB [RFC.ZLIB], DEFLATE [RFC.DEFLATE] and GZIP [RFC.GZIP] respectively.
Reserved, 16 bits:
This field MUST be set to all '0'. This field SHOULD be ignored on reception.
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.
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.
ALC/LCT has a concept of channels and congestion control. There are four scenarios in which FLUTE is envisioned to be applied.
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 transmission 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:
FLUTE inherits the use of FEC building block [RFC5052] 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 [ID.ALC-revised] and the use of FDT. The latter method is specified in this section. The use of EXT_FTI requires repetition of the FEC Object Transmission Information to ensure reception (though not necessarily in every packet) and thus may entail higher overhead than the use of the FDT, but may also provide more timely delivery of the FEC Object Transmission Information.
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). The FEC Object Transmission Information that MUST be delivered to receivers is defined by the FEC Scheme. This section 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 prioritize the sources in the following way (in the order of decreasing priority).
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.
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.
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 [ID.ALC-revised], the transport parameters of an ALC/LCT session that the receiver needs to know are:
Optionally, the following parameters MAY be associated with the session (Note, the list is not exhaustive):
It is envisioned that these parameters would be described according to some session description syntax (such as SDP [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 [RFC.SAP], email, HTTP [RFC.HTTP11], SIP [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.
A content delivery system is potentially subject to attacks. Attacks may target: Section 7.5.
These attacks can be launched either:
In the following sections we provide more details on these possible attacks and sketch some possible counter-measures. We provide recommendations in
Let us consider attacks against the data flow first. At least, the following types of attacks exist:
Access control to the file being transmitted is typically provided by means of encryption. This encryption can be done over the whole file i.e. before applying FEC protection (e.g., by the content provider, before submitting the file to FLUTE), or be done on a packet per packet basis (e.g., when IPsec/ESP is used [RFC.4303], see Section 7.5). If confidentiality is a concern, it is RECOMMENDED that one of these solutions be used.
Protection against corruptions (e.g., if an attacker sends forged packets) is achieved by means of a content integrity verification/sender authentication scheme. This service can be provided at the file level i.e. before applying content encoding and forward error correction encoding. In that case a receiver has no way to identify which symbol(s) is(are) corrupted if the file is detected as corrupted. This service can also be provided at the packet level i.e. after applying content encoding and forward error correction encoding, on a packet by packet basis. In this case, after removing all corrupted packets, the file may be in some cases recovered from the remaining correct packets.
Integrity protection applied at the file level has the advantage of lower overhead since only relatively few bits are added to provide the integrity protection compared to the file size. However it has the disadvantage that it cannot distinguish between correct packets and corrupt packets and therefore correct packets, which may form the majority of packets received, may be unusable. Integrity protection applied at the packet level has the advantage that it can distinguish between correct and corrupt packets at the cost of additional per packet overhead.
Several techniques can provide this source authentication/content integrity service:
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.
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).
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.
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:
The consequences of these attacks are potentially serious, since they might compromise the behavior of content delivery system itself.
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.
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.
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.
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.
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 (Section 7.2.2) 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 [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.
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.
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 (Section 7.2.2) SHOULD be used.
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.
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.
When congestion control building block is applied with FLUTE, it is also RECOMMENDED that a packet level authentication scheme be used, as explained in Section 7.2.2. Some of them, like TESLA, only provide a delayed authentication service, whereas congestion control requires a rapid reaction. It is therefore RECOMMENDED [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.
Lastly, we note that the security considerations that apply to, and are described in, ALC [ID.ALC-revised], LCT [RFC.LCT] and FEC [RFC5052] 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.
We now introduce a mandatory to implement but not necessarily to use security configuration, in the sense of [RFC.3365]. Since FLUTE relies on ALC/LCT, it inherits the "baseline secure ALC operation" of [ID.ALC-revised]. More precisely, security is achieved by means of IPsec/ESP in transport mode. [RFC.4303] explains that ESP can be used to potentially provide confidentiality, data origin authentication, content integrity, anti-replay and (limited) traffic flow confidentiality. [ID.ALC-revised] specifies that the data origin authentication, content integrity and anti-replay services SHALL be supported, and that the confidentiality service is RECOMMENDED. If a short lived session MAY rely on manual keying, it is also RECOMMENDED that an automated key management scheme be used, especially in case of long lived sessions.
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.
This specification contains five separate items for IANA Considerations:
Document [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.
Registrant Contact: Toni Paila (toni.paila (at) nokia.com)
XML: The XML Schema specified in Section 3.4.2
This section provides the registration request, as per [RFC.MIME4a], [RFC.MIME4b] and [RFC.XML-Media-Types], to be submitted to IANA following IESG approval.
Type name: application
Subtype name: fdt+xml
Required parameters: none
Optional parameters: none
Encoding considerations: The fdt+xml type consists of UTF-8 ASCII characters [RFC.UTF8] and must be well-formed XML.
Additional content and transfer encodings may be used with fdt+xml files, with the appropriate encoding for any specific file being entirely dependent upon the deployed application.
Restrictions on usage: Only for usage with FDT Instances which are valid according to the XML schema of section 3.4.2.
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.
Interoperability considerations: None
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.
Applications which use this media type: Not restricted to any particular application
Additional information:
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
Person and email address to contact for further information: Toni Paila (toni.paila (at) nokia.com)
Intended usage: Common
Author/Change controller: IETF
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.
This document defines a name-space called "Content Encoding Algorithms".
IANA has established and manages the new registry for the "FLUTE Content Encoding Algorithm" name-space. The values that can be assigned within this name-space are numeric indexes in the range [0, 255], boundaries included. Assignment requests are granted on a "Specification Required" basis as defined in RFC 2434 [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.
This document registers value 192 for the EXT_FDT LCT Header Extension defined in Section 3.4.1.
This document registers value 193 for the EXT_CENC LCT Header Extension defined in Section 3.4.3.
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.
Jani Peltotalo
Tampere University of Technology
P.O. Box 553 (Korkeakoulunkatu 1)
Tampere FIN-33101
Finland
Email: jani.peltotalo (at) tut.fi
Sami Peltotalo
Tampere University of Technology
P.O. Box 553 (Korkeakoulunkatu 1)
Tampere FIN-33101
Finland
Email: sami.peltotalo (at) tut.fi
Magnus Westerlund
Ericsson Research
Ericsson AB
SE-164 80 Stockholm
Sweden
EMail: magnus.westerlund (at) ericsson.com
Thorsten Lohmar
Ericsson Research (EDD)
Ericsson Allee 1
52134 Herzogenrath, Germany
EMail: thorsten.lohmar (at) ericsson.com
Incremented FLUTE protocol version from 1 to 2, due to IESG concerns about backwards compatibility.
Updated dependencies to other RFCs to revised versions, e.g., changed ALC reference from RFC 3450 to RFC 5775, changed LCT reference from RFC 3451 to RFC 5651, etc.
Two additional items are added in the IANA considerations section, specifically the registration of two values in the LCT Header Extension Types registry (192 for EXT_FDT and 193 for EXT_CENC).
Added clarification for the use of FLUTE for unicast communications in Section 1.1.4.
Clarified how to reliably deliver the FDT in Section 3.3 and the possibility of using an out-of-band delivery of FDT information.
Clarified how to address FDT Instance expiration time wraparound with the notion of "epoch" of NTPv4 in Section 3.3.
Clarified what should be considered as erroneous situations in Section 3.4.1 (definition of FDT Instance ID). In particular a receiver MUST be ready to handle FDT Instance ID wraparounds and missing FDT Instances.
Updated the security section to define IPsec/ESP as a mandatory to implement security solution in Section 7.5.
Removed the 'Statement of Intent' from the Section 1. 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.
Added clarification on XML-DSIG in the end of Section 3.
Revised the use of word "complete" in the Section 3.2.
Clarified Figure 1 WRT "Encoding Symbol(s) for FDT Instance".
Clarified the FDT Instance ID wrap-around in the end of Section 3.4.1.
Clarification for "Complete FDT" in the Section 3.4.2.
Added semantics for the case two TOIs refer to same Content-Location. Now it is in line how 3GPP and DVB interpret the case.
In the Section 3.4.2 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.
Clarified FDT-schema extensibility in the end of Section 3.4.2.
The CENC value allocation is added in the end of Section 3.4.3.
Section 5 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.
Added a clarifying paragraph on the use of Codepoint in the very end of Section 5.
Reworked Section 8 - IANA Considerations. Now it contains three IANA registration requests:
Added Section 10 - Contributors.
Revised list of both Normative as well as Informative references.
Added a clarification that receiver should ignore reserved bits of Header Extension type 193 upon reception.
Minor changes to remove forward references (use before definition) or refer to forward reference sections.
Elaborate on just what kind of networks cannot support FLUTE congestion control (1.1.4)
In Section 3.2 revise "several" (meaning 3-n vs. "couple" = 2) to "multiple" (meaning 2-n)
Move Section 3.3 requirement to send FDT more reliably than files, to a bulleted RECOMMENDED requirement, making check-off easier for testers.
Sharpen Section 3.3 definition that future FDT file instances can "augment" (meaning enhance) rather than "complement" (sometimes meaning negate, which is not allowed) the file parameters.
Elaborate in Section 3.3 and Section 4 that FEC Encoding ID = 0 is Compact No-code FEC, so that the reader doesn't have to search other RFCs to understand these protocol constants used by FLUTE.
Require in Section 3.3 that FLUTE receivers SHALL NOT attempt to decode FDTs if they do not understand the FEC Encoding ID
Remove restriction of Section 3.3 in bullet #4 that TOI=0 for the FDT, to be consistent with Appendix, bullet 6, and elsewhere. An FDT is signaled by an FDT Instance ID, NOT only by TOI = 0.
Standardize on the term "expiration time" and avoid using the redundant but possibly confusing term "expiry time".
To interwork with experimental flute, stipulate in Section 3.1 that only 1 instantiation of all 3 protocols FLUTE, ALC, and LCT, can be associated with a session (source IP-Address, TSI) and mention in Section 6 that you may (optionally) derive the FLUTE version from the file delivery session description.
Use a software writing tool to lower reading grade level and simplify Section 3.1.
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.
<?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>