Toni Paila

Rod Walsh

Michael Luby

Vincent Roca

Rami Lehtonen

FLUTE -File Delivery over Unidirectional Transport

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

This document defines FLUTE version 2, a protocol for unidirectional delivery of files over the Internet. This specification is not backwards compatible with the previous experimental version defined in [START_REF] Paila | FLUTE -File Delivery over Unidirectional Transport[END_REF] (see Section 11 for details). The specification builds on Asynchronous Layered Coding (ALC), version 1 [START_REF] Luby | Asynchronous Layered Coding (ALC) Protocol Instantiation[END_REF], 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 This document defines a specific transport application of ALC, adding the following specifications:

-Definition of a file delivery session built on top of ALC, including transport details and timing constraints.

-In-band signaling of the transport parameters of the ALC session.

-In-band signaling of the properties of delivered files.

-Details associated with the multiplexing of multiple files within a session.

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, which 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 (RMT) protocol in accordance with [RFC2357].

This document obsoletes [START_REF] Paila | FLUTE -File Delivery over Unidirectional Transport[END_REF], which contained a previous version of this specification and was published in the "Experimental" category. This Proposed Standard specification is thus based on [START_REF] Paila | FLUTE -File Delivery over Unidirectional Transport[END_REF] and has been updated according to accumulated experience and growing protocol maturity since the publication of [START_REF] Paila | FLUTE -File Delivery over Unidirectional Transport[END_REF]. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification.

Paila, et al.

Standards Track [Page 4]

The differences between [START_REF] Paila | FLUTE -File Delivery over Unidirectional Transport[END_REF] and this document are listed in Section 11.

This document updates ALC [START_REF] Luby | Asynchronous Layered Coding (ALC) Protocol Instantiation[END_REF] and Layered Coding Transport (LCT) [START_REF] Luby | Layered Coding Transport (LCT) Building Block[END_REF] in the sense that it defines two new header extensions, EXT_FDT and EXT_CENC.

1.1. Applicability Statement 1.1.1. The Target Application Space 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, Session Description Protocol (SDP) [START_REF] Handley | SDP: Session Description Protocol[END_REF] files that enable user applications to access multimedia sessions.

The Target Scale

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 by using ALC and IP multicast without sacrificing any of the inherent scalability of IP multicast.

Intended Environments

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 [START_REF] Luby | Asynchronous Layered Coding (ALC) Protocol Instantiation[END_REF], the LCT building block [START_REF] Luby | Layered Coding Transport (LCT) Building Block[END_REF], and the FEC building block [START_REF] Watson | Forward Error Correction (FEC) Building Block[END_REF].

FLUTE can be used with both multicast and unicast delivery, but its primary application is for unidirectional multicast file delivery. FLUTE requires connectivity between a sender and receivers but does not require connectivity from receivers to a sender. Because of its low expectations, FLUTE works with most types of networks, including LANs, WANs, Intranets, the Internet, asymmetric networks, wireless networks, and satellite networks. 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.

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 [RFC2119].

The terms "object" and "transmission object" are consistent with the definitions in ALC [START_REF] Luby | Asynchronous Layered Coding (ALC) Protocol Instantiation[END_REF] and LCT [START_REF] Luby | Layered Coding Transport (LCT) Building Block[END_REF]. The terms "file" and "source object" are pseudonyms for "object". 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.

* Identifier of the file, expressed as a URI [START_REF] Berners-Lee | Uniform Resource Identifier (URI): Generic Syntax[END_REF]. The identifier MAY provide a location for the file. In the above example: "http://www.example.com/docs/file.txt".

* File name (usually, this can be concluded from the URI). In the above example: "file.txt".

* File type, expressed as Internet Media Types (often referred to as "Media Types"). In the above example: "text/plain".

* File size, expressed in octets. In the above example: "5200". If the file is content encoded, then this is the file size before content encoding.

* Content encoding of the file, within transport. In the above example, the file could be encoded using ZLIB [RFC1950]. In this case, the size of the transmission object carrying the file would probably differ from the file size. The transmission object size is delivered to receivers as part of the FLUTE protocol.

* Security properties of the file, such as digital signatures, message digests, etc. For example, one could use S/MIME [START_REF] Ramsdell | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification[END_REF] as the content encoding type for files with this authentication wrapper, and one could use XML Digital Signatures (XML-DSIG) [START_REF] Eastlake ; Rd | Extensible Markup Language) XML-Signature Syntax and Processing[END_REF] to digitally sign the file. XML-DSIG can also be used to provide tamper prevention, e.g., in the Content-Location field. Content encoding is applied to file data before FEC protection.

File Delivery Session

ALC is a protocol instantiation of the Layered Coding Transport (LCT) building block [START_REF] Luby | Layered Coding Transport (LCT) Building Block[END_REF]. Thus, ALC inherits the session concept of LCT. In this document, we will use the concept of the 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), an integer carried in a field of size 16, 32, or 48 bits (note that the TSI may be carried by other means, in which case it is absent from the LCT header [START_REF] Luby | Layered Coding Transport (LCT) Building Block[END_REF]). 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 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. This object received with an unmapped TOI (non-zero TOI that is not resolved by the FDT) SHOULD in general be ignored by a FLUTE receiver. The details of how to do that are out of scope of this specification.

Note that a client that joins an active file delivery session MAY receive data packets for a TOI > 0 before receiving any FDT Instance (see Section 3.3 for recommendations on how to limit the probability that this situation will occur). Even if the TOI is not mapped to any file description entry, this is hopefully a transient situation.

When this happens, system performance might be improved by caching such packets within a reasonable time window and storage size. Such optimizations are use-case and implementation specific, and further details are beyond the scope of this document.

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, be a subset of, be 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.

Dynamics of FDT Instances within a File Delivery Session

The following rules define the dynamics of the FDT Instances within a file delivery session:

* For every file delivered within a file delivery session, there MUST be a file description entry included in at least one FDT Instance sent within the session. A file description entry contains at a minimum the mapping between the TOI and the URI.

* An FDT Instance MAY appear in any part of the file delivery session, and packets for an FDT Instance MAY be interleaved with packets for other files or other FDT Instances within a session.

* The TOI value of '0' MUST be reserved for delivery of FDT Instances. The use of other TOI values (i.e., an integer > 0) for FDT Instances is outside the scope of this specification.

* The FDT Instance is identified by the use of a new fixed-length LCT Header Extension, EXT_FDT (defined later in this section). Each non-expired FDT Instance is uniquely identified within the file delivery session by its FDT Instance ID, carried by the EXT_FDT Header Extension. Any ALC/LCT packet carrying an FDT Instance MUST include EXT_FDT.

* It is RECOMMENDED that an FDT Instance that contains the file description entry for a file be sent at least once before sending the described file within a file delivery session. This recommendation is intended to minimize the amount of file data that may be received by receivers in advance of the FDT Instance containing the entry for a file (such data must either be speculatively buffered or discarded). Note that this possibility cannot be completely eliminated, since the first transmission of FDT data might be lost.

* Within a file delivery session, any TOI > 0 MAY be described more than once. For example, a previous FDT Instance 0 describes a TOI of value '3'. Now, subsequent FDT Instances can either keep TOI '3' unmodified in the table, not include it, or augment the description. However, subsequent FDT Instances MUST NOT change the parameters already described for a specific TOI.

* An FDT Instance is valid until its expiration time. The expiration time is expressed within the FDT Instance payload as a UTF-8 decimal representation of a 32-bit unsigned integer. The value of this integer represents the 32 most significant bits of a 64-bit Network Time Protocol (NTP) [START_REF] Mills | Network Time Protocol Version 4: Protocol and Algorithms Specification[END_REF] time value. These 32 bits provide an unsigned integer representing the time in 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 that 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. 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 at least as reliably 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 a higher delivery probability than the file recovery probability. The sender MAY also continue sending the various file attributes in-band, in addition to the out-of-band transmission. The FDT Instance Header (EXT_FDT) is a new fixed-length, ALC Protocol-Instantiation-specific LCT Header Extension [START_REF] Luby | Layered Coding Transport (LCT) Building Block[END_REF]. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: EXT_FDT Format Version of FLUTE (V), 4 bits:
This document specifies FLUTE version 2. Hence, in any ALC packet that carries an 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 ID 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. Then, the subsequent FDT Instances are assigned the next available smallest FDT Instance ID value, in order to always keep the FDT Instance ID values logically increasing.

Senders MUST NOT reuse 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 MUST be considered an error case. Receiver behavior in this case (e.g., leave the session or ignore the new FDT Instance) is outside the scope of this specification and left to individual implementations of FLUTE. Receivers MUST be ready to handle FDT Instance ID wraparound and situations where missing FDT Instance IDs result in increments larger than one. The FDT Instance contains file description entries that provide the mapping functionality described in Section 3.2 above.

The FDT Instance is an Extensible Markup Language (XML) structure that has a single root element "FDT-Instance". The "FDT-Instance" element MUST contain the "Expires" attribute, which provides the expiration time of the FDT Instance. In addition, the "FDT-Instance" element MAY contain the "Complete" attribute, a boolean that can be either set to '1' or 'true' for TRUE, or '0' or 'false' for FALSE.

When TRUE, the "Complete" attribute signals that this "FDT Instance" includes the set of "File" entries that exhausts both the set of files delivered so far and 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 file parameters identical 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"). Note that when all the FDT Instances received so far have no "Complete" attribute, the receiver MUST consider that the session is not complete and that new data MAY be provided in future FDT Instances. This is equivalent to receiving FDT Instances having the "Complete" attribute set to FALSE.

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 the "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 the MIME field name, and the XML attribute value corresponds to the value of the MIME field body [RFC2045]. 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. "Content-Location" [RFC2616] MUST be assigned a syntactically valid URI, as defined in [START_REF] Berners-Lee | Uniform Resource Identifier (URI): Generic Syntax[END_REF], which identifies the file to be delivered. For example, it can be a URI with the "http" or "file" URI scheme. Only one "Content-Location" attribute is allowed for each file. The "Content-Location" field MUST be considered a string that identifies a file (i.e., two different strings are two different identifiers). Any use of the "Content-Location" field for anything else other than to identify the object is out of scope of this specification. 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 a 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 attribute "Content-Type" SHOULD be included and, when present, MUST be used for the purpose defined in [RFC2616].

* Where the length is described, the attribute "Content-Length" MUST be used for the purpose defined in [RFC2616]. The transfer length is defined to be the length of the object transported in octets.

It is often important to convey the transfer length to receivers, because the source block structure needs to be known for the FEC decoder to be applied to recover source blocks of the file, and the transfer length is often needed to properly determine the source block structure of the file. There generally will be a difference between the length of the original file and the transfer length if content encoding is applied to the file before transport, and thus the "Content-Encoding" attribute is used. If the file is not content encoded before transport (and thus the "Content-Encoding" attribute is not used), then the transfer length is the length of the original file, and in this case the "Content-Length" is also the transfer length. However, if the file is content encoded before transport (and thus the "Content-Encoding" attribute is used), e.g., if compression is applied before transport to reduce the number of octets that need to be transferred, then the transfer length is generally different than the length of the original file, and in this case the attribute "Transfer-Length" MAY be used to carry the transfer length.

* Whenever content encoding is applied, the attribute "Content-Encoding" MUST be included. Whenever the attribute "Content-Encoding" is included, it MUST be used as described in [RFC2616].

Paila, et al.

Standards Track [Page 18]

* Where the MD5 message digest is described, the attribute "Content-MD5" MUST be used for the purpose defined in [RFC2616].

Note that the goal is to provide a decoded object integrity service in cases where transmission and/or FLUTE/ALC processing errors may occur (the probability of collision is in that case negligible). It MUST NOT be regarded as a security mechanism (see Section 7 for information regarding security measures).

* The FEC Object Transmission Information attributes are described in Section 5.

The following specifies the XML Schema [XML-Schema-Part-1] [XML-Schema-Part-2] for the 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"/> Paila, et al.

Standards Track [Page 19]

<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"/> Paila, et al.

Standards Track [Page 20]

<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 Figure 3: XML Schema for the FDT Instance Any valid FDT Instance MUST use the above XML Schema. This way, FDT provides extensibility to support private elements and private attributes within the file description entries. Those could be, for example, the attributes related to the delivery of the file (timing, packet transmission rate, etc.). Unsupported private elements and attributes SHOULD be silently ignored by a FLUTE receiver.

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 be in the format of message header fields and be either defined in the HTTP/1.1 specification [RFC2616] or another well-known specification, or in an IANA registry [IANAheaderfields]. However, this specification doesn't prohibit the use of other formats to allow private attributes to be used when interoperability is not a concern.

Content Encoding of FDT Instance

The FDT Instance itself MAY be content encoded (e.g., compressed). This specification defines the FDT Instance Content Encoding Header (EXT_CENC). EXT_CENC is a new fixed-length LCT Header Extension [START_REF] Luby | Layered Coding Transport (LCT) Building Block[END_REF]. The Header Extension Type (HET) for the extension is 193. If the FDT Instance is content encoded, EXT_CENC MUST be used to signal the content encoding type. In that case, the EXT_CENC Header Extension MUST be used in all ALC packets carrying the same FDT Instance ID. Consequently, when the 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 Paila, et al.

Standards Track [Page 21]

content encoding is not used for a given FDT Instance, 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 +- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved, 16 bits: This field MUST be set to all '0's. This field MUST be ignored on reception.

Multiplexing of Files within a File Delivery Session

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 might 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. 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 mean that the delivery of the second object is completed 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 be 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 are RECOMMENDED:

1. The layers to which packets for FDT Instances are sent SHOULD NOT be biased towards those layers to which lower-rate receivers are not joined. For example, it is okay to put all the packets for an FDT Instance into the lowest layer (if this layer carries enough packets to deliver the FDT to higher-rate receivers in a reasonable amount of time), but it is not okay to put all the packets for an FDT Instance into the higher layers that only higher-rate receivers will receive.

2. If FDT Instances are generally longer than one Encoding Symbol in length and some packets for FDT Instances are sent to layers that lower-rate receivers do not receive, an FEC encoding other than Compact No-Code FEC Encoding ID 0 [RFC5445] SHOULD be used to deliver FDT Instances. This is because in this case, even when there is no packet loss in the network, a lower-rate receiver will not receive all packets sent for an FDT Instance.

Delivering FEC Object Transmission Information

FLUTE inherits the use of the FEC building block [START_REF] Watson | Forward Error Correction (FEC) Building Block[END_REF] 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 the ALC-specific LCT Header Extension EXT_FTI [START_REF] Luby | Asynchronous Layered Coding (ALC) Protocol Instantiation[END_REF] and the use of the 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 a file delivery session MUST support delivery of FEC Object Transmission Information using 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 the 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 the 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 the 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 order of decreasing priority).

1. FEC Object Transmission Information that is available in EXT_FTI.

FEC Object Transmission

Information that is available in the FDT.

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.

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 represent the entry point from which thereafter the receiver operation falls into the scope of this specification. According to [START_REF] Luby | Asynchronous Layered Coding (ALC) Protocol Instantiation[END_REF], the transport parameters of an ALC/LCT session that the receiver needs to know are:

* The source 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 that the session is a FLUTE session. The need to demultiplex objects upon reception is implicit in any use of FLUTE, and this fulfills the ALC requirement of an indication of whether or not a session carries packets for more than one object (all FLUTE sessions carry packets for more than one object).

Optionally, the following parameters MAY be associated with the session (note that the list is not exhaustive): It is envisioned that these parameters would be described according to some session description syntax (such as SDP [START_REF] Handley | SDP: Session Description Protocol[END_REF] or XML based) and held in a file that would be acquired by the receiver before the FLUTE session begins by means of some transport protocol (such as the Session Announcement Protocol (SAP) [RFC2974], email, HTTP [RFC2616], SIP [START_REF] Rosenberg | SIP: Session Initiation Protocol[END_REF], manual preconfiguration, 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.

*

Security Considerations

Problem Statement

A content delivery system is potentially subject to attacks. Attacks may target:

* the network (to compromise the routing infrastructure, e.g., by creating congestion), * the Content Delivery Protocol (CDP) (e.g., to compromise the normal behavior of FLUTE), or * the content itself (e.g., to corrupt the files being transmitted).

These attacks can be launched either:

* against the data flow itself (e.g., by sending forged packets), * against the session control parameters (e.g., by corrupting the session description, the FDT Instances, or the ALC/LCT control parameters) that are sent either in-band or out-of-band, or * against some associated building blocks (e.g., the congestion control component).

In the following sections, we provide more details on these possible attacks and sketch some possible countermeasures. We provide recommendations in Section 7.5. * attacks that are meant to give access to a confidential file (e.g., in the case of non-free content) and * attacks that try to corrupt the file being transmitted (e.g., to inject malicious code within a file, or to prevent a receiver from using a file, which is a kind of denial of service (DoS)).

Access to Confidential Files

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 can be done on a packet-by-packet basis (e.g., when IPsec/ESP [START_REF] Kent | IP Encapsulating Security Payload (ESP)[END_REF] is used; see Section 7.5). If confidentiality is a concern, it is RECOMMENDED that one of these solutions be used.

File Corruption

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 FEC 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 FEC 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. * At the packet level, each packet can be digitally signed [START_REF] Roca | Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols[END_REF]. A major limitation is the high computational and transmission overheads that this solution requires. To avoid this problem, the signature may span a set of symbols (instead of a single one) in order to amortize the signature calculation, but if a single symbol is missing, the integrity of the whole set cannot be checked.

* At the packet level, a Group-Keyed Message Authentication Code (MAC) [RFC2104] [RFC6584] scheme can be used; an example is using HMAC-SHA-256 with a secret key shared by all the group members, senders, and receivers. This technique creates a cryptographically secured digest of a packet that is sent along with the packet. The Group-Keyed MAC scheme does not create prohibitive processing load or transmission overhead, but it has a major limitation: it only provides a group authentication/ integrity service, since all group members share the same secret group key, which means that each member can send a forged packet.

It is therefore restricted to situations where group members are fully trusted (or in association with another technique as a pre-check).

* At the packet level, Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [START_REF] Perrig | Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction[END_REF] [RFC5776] is an attractive solution that is robust to losses, provides a true authentication/ integrity service, and does not create any prohibitive processing load or transmission overhead. However, checking a packet requires a small delay (a second or more) after its reception.

* At the packet level, IPsec/ESP [START_REF] Kent | IP Encapsulating Security Payload (ESP)[END_REF] can be used to check the integrity and authenticate the sender of all the packets being exchanged in a session (see Section 7.5).

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 Techniques relying on symmetric key cryptography (Group-Keyed 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. The consequences of these attacks are potentially serious, since they might compromise the behavior of the content delivery system itself.

Attacks against the Session Description

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.

Attacks against the FDT Instances

Corrupting the FDT Instances is one way to create a DoS 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) would be used instead of GF(2^^8) with FEC Encoding ID 2. This may significantly increase the processing load while compromising FEC decoding.

More generally, because FDT Instance data is structured using the XML language by means of an XML media type, many of the security considerations described in [START_REF] Murata | XML Media Types[END_REF] and [START_REF] Hollenbeck | Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols[END_REF] also apply to such data.

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 countermeasures 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 [START_REF] Eastlake ; Rd | Extensible Markup Language) XML-Signature Syntax and Processing[END_REF] 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 countermeasures mentioned above (Section 7.2.2) SHOULD be used.

Attacks against the Associated Building Blocks

Let us first focus on the congestion control building block, which 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 the congestion control building block is applied with FLUTE, it is 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 receiver from launching an attack, this authentication will enable the network operator to identify him and to take countermeasures.

When the 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 [START_REF] Luby | Asynchronous Layered Coding (ALC) Protocol Instantiation[END_REF] that a receiver using TESLA quickly reduce its subscription level when the receiver believes that 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 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-Keyed MAC scheme could be used in parallel with TESLA to prevent attacks launched from outside of the group.

Other Security Considerations

The security considerations that apply to, and are described in, ALC [START_REF] Luby | Asynchronous Layered Coding (ALC) Protocol Instantiation[END_REF], LCT [START_REF] Luby | Layered Coding Transport (LCT) Building Block[END_REF], 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.

Even if FLUTE defines a purely unidirectional delivery service, without any feedback information that would be sent to the sender, security considerations MAY require bidirectional communications. For instance, if an automated key management scheme is used, a bidirectional point-to-point channel is often needed to establish a shared secret between each receiver and the sender. Each shared secret can then be used to distribute additional keys to the associated receiver (e.g., traffic encryption keys).

As an example, [MBMSsecurity] details a complete security framework for the Third Generation Partnership Project (3GPP) Multimedia Broadcast/Multicast Service (MBMS) that relies on FLUTE/ALC for Download Sessions. It relies on bidirectional point-to-point communications for User Equipment authentication and for key distribution, using the Multimedia Internet KEYing (MIKEY) protocol [START_REF] Arkko | MIKEY: Multimedia Internet KEYing[END_REF]. Because this security framework is specific to this use case, it cannot be reused as such for generic security recommendations in this specification. Instead, the following section introduces minimum security recommendations.

Minimum Security Recommendations

We now introduce a mandatory-to-implement, but not necessarily to use, security configuration, in the sense of [START_REF] Schiller | Strong Security Requirements for Internet Engineering Task Force Standard Protocols[END_REF]. Since FLUTE relies on ALC/LCT, it inherits the "baseline secure ALC operation" of [START_REF] Luby | Asynchronous Layered Coding (ALC) Protocol Instantiation[END_REF]. More precisely, security is achieved by means of IPsec/ ESP in transport mode. [START_REF] Kent | IP Encapsulating Security Payload (ESP)[END_REF] explains that ESP can be used to potentially provide confidentiality, data origin authentication, content integrity, anti-replay, and (limited) traffic flow confidentiality. [START_REF] Luby | Asynchronous Layered Coding (ALC) Protocol Instantiation[END_REF] 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 the 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. The CENC value allocation has been added at the end of Section 3.4.3.

Section 5 has been modified so that EXT_FTI and the FEC issues were replaced by a reference to the ALC specification [START_REF] Luby | Asynchronous Layered Coding (ALC) Protocol Instantiation[END_REF]. Elaborated on what kinds of networks cannot support FLUTE congestion control (Section 1.1.4).

In Section 3.2, changed "several" (meaning 3-n vs. "couple" = 2) to "multiple" (meaning 2-n).

Moved the requirement in Section 3.3 (to send FDT more reliably than files) to a bulleted RECOMMENDED requirement, making check-off easier for testers.

In Section 3.3, sharpened the definition that future FDT file instances can "augment" (meaning enhance) rather than "complement" (sometimes meaning negate, which is not allowed) the file parameters.

Elaborated in Sections 3.3 and 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.

  1. Introduction ....................................................3 1.1. Applicability Statement ....................................5 1.1.1.The Target Application Space ........................5 1.1.2. The Target Scale ....................................5 1.1.3. Intended Environments ...............................5 1.1.4. Weaknesses ..........................................6 2. Conventions Used in This Document ...............................6 3. File Delivery ...................................................7 3.1. File Delivery Session ......................................8 3.2. File Delivery Table .......................................10 3.3. Dynamics of FDT Instances within a File Delivery Session ..12 3.4. Structure of FDT Instance Packets .........................15 3.4.1. Format of FDT Instance Header ......................16 3.4.2. Syntax of FDT Instance .............................17 3.4.3. Content Encoding of FDT Instance ...................21 3.5. Multiplexing of Files within a File Delivery Session ......22 4. Channels, Congestion Control, and Timing .......................23 5. Delivering FEC Object Transmission Information .................24 6. Describing File Delivery Sessions .............................

Paila

Figure

  Figure 1: Overall FDT Packet

  Figure 4: EXT_CENC Format 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 [RFC1950], DEFLATE [RFC1951], and GZIP [RFC1952], respectively.

7. 3 .

 3 Attacks against the Session Control Parameters and Associated Building BlocksLet 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 attack can target the session description, * the attack can target the FDT Instances, * the attack can target the ALC/LCT parameters, carried within the LCT header, or * the attack can target the FLUTE associated building blocks (e.g., the multiple-rate congestion control protocol).

+

  -------+----------------+-----------+ | Value | Algorithm Name | Reference | +-------+----------------+--------------+----------------+-----------+8.5. Registration of LCT Header Extension TypesIANA has registered two new entries in the "Layered Coding Transport (LCT) Header Extension Types" registry[START_REF] Luby | Layered Coding Transport (LCT) Building Block[END_REF], as follows:+--------+----------+------------------------------+----------+-------------------------+ | 192 | EXT_FDT | [RFC6726] Section 3.4.1 | | 193 | EXT_CENC | [RFC6726] Section 3.4.3 | +--------+----------+-------------------------+9. AcknowledgmentsThe following persons have contributed to this specification: Brian Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma, Topi Pohjolainen, Lorenzo Vicisano, Mark Watson, David Harrington, Ben Campbell, Stephen Farrell, Robert Sparks, Ronald Bonica, Francis Dupont, Peter Saint-Andre, Don Gillies, and Barry Leiba. The authors would like to thank all the contributors for their valuable work in reviewing and providing feedback regarding this specification. Paila, et al. Standards Track [Page 36]

  Added a clarifying paragraph on the use of the Codepoint field at the end of Section 5. Reworked Section 8 --IANA Considerations; it now contains six IANA registration requests: * Registration of the FDT Instance XML Namespace. * Registration of the FDT Instance XML Schema. * Registration of the application/fdt+xml Media Type. * Registration of the Content Encoding Algorithms. * Registration of two LCT Header Extension Types and corresponding values in the LCT Header Extension Types Registry (192 for EXT_FDT and 193 for EXT_CENC).Added Section 10 --Contributors.Revised lists of both Normative and Informative references.Added a clarification that the receiver should ignore reserved bits of Header Extension type 193 upon reception.

  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.

	RFC 6726	FLUTE	November 2012
	Paila, et al.	Standards Track	[Page 7]

  January 1900 in the case of the prime epoch (era 0)[START_REF] Mills | Network Time Protocol Version 4: Protocol and Algorithms Specification[END_REF]. The handling of time wraparound (to happen in 2036) requires that the associated epoch be considered. In any case, both a sender and a receiver easily determine to which (136-year) epoch the FDT Instance expiration time value pertains by choosing the epoch for which the expiration time is closest in time to the current time.Here is an example. Let us imagine that a new FLUTE session is started on February 7th, 2036, 0h, i.e., at NTP time 4,294,944,000, a few hours before the end of epoch 0. In order to define an FDT Instance valid for the next 48 hours, The FLUTE sender sets an expiry time of 149,504. This FDT Instance will expire exactly on February 9th, 2036, 0h. A client that receives this FDT Instance on the 7th, 0h, just after it has been sent, immediately understands that this value corresponds to epoch 1. A client that joins the session on February 8th, 0h, i.e., at NTP time 63,104, epoch 1, immediately understands that the 149,504 NTP timestamp corresponds to epoch 1. It is RECOMMENDED that the mechanisms used for file attribute delivery SHOULD achieve a delivery probability that is higher than the file recovery probability and the file attributes SHOULD be delivered at this higher priority before the delivery of the associated files begins.

	Paila, et al. seconds relative to 0 hours 1 Paila, et al. Standards Track Standards Track	[Page 12] [Page 13]

* The space of FDT Instance IDs is limited by the associated field size (i.e., 20 bits) in the EXT_FDT Header Extension (Section 3.4.1). Therefore, senders should take care to always have a large enough supply of available FDT Instance IDs when specifying FDT expiration times. * The receiver MUST NOT use a received FDT Instance to interpret packets received beyond the expiration time of the FDT Instance. * A sender MUST use an expiration time in the future upon creation of an FDT Instance relative to its Sender Current Time (SCT). * Any FEC Encoding ID MAY be used for the sending of FDT Instances. The default is to use the Compact No-Code FEC Encoding ID 0 [RFC5445] for the sending of FDT Instances. (Note that since FEC Encoding ID 0 is the default for FLUTE, this implies that Source Block Number and Encoding Symbol ID lengths both default to 16 bits each.) * If the receiver does not support the FEC Scheme indicated by the FEC Encoding ID, the receiver MUST NOT decode the associated FDT. *

  Structure of FDT Instance PacketsFDT 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. Placement of the FDT Instance Header is the same as that of any other LCT Header Extension. There MAY be other LCT Header Extensions 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 Header Extensions are followed by the FEC Payload ID, and finally the Encoding Symbols for the FDT Instance, which contains one or more file description entries. An 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.

	RFC 6726	FLUTE	November 2012
	3.4.
	Paila, et al.	Standards Track	[Page 14]

The overall format of ALC/LCT packets carrying an FDT Instance is depicted in Figure

1

below. All integer fields are carried in "big-endian" or "network order" format (i.e., most significant byte (octet) first). As defined in

[START_REF] Luby | Asynchronous Layered Coding (ALC) Protocol Instantiation[END_REF]

, all ALC/LCT packets are sent using UDP. FLUTE Payload: Encoding Symbol(s) ˜ (for FDT Instance in an FDT packet) ˜

  The start time and end time of the session;

	RFC 6726	FLUTE	November 2012
	* Security parameters relevant for the session;
	* FLUTE version number.
	* FEC Encoding ID and FEC Instance ID when the default FEC Encoding
	ID 0 is not used for the delivery of the FDT;
	* Content encoding format if optional content encoding of the FDT
	Instance is used, e.g., compression;
	* Some information that tells receiver, in the first place, that the
	session contains files that are of interest;
	* Definition and configuration of a congestion control mechanism for
	the session;
	Paila, et al.	Standards Track	[Page 26]

  Attacks against the Data FlowLet us consider attacks against the data flow first. At the least, the following types of attacks exist:

	RFC 6726	FLUTE	November 2012
	7.2.
	Paila, et al.	Standards Track	[Page 27]

  Registration of the FDT Instance XML Namespace. 2. Registration of the FDT Instance XML Schema. 3. Registration of the application/fdt+xml Media Type. 4. Registration of the Content Encoding Algorithms. 5. Registration of two LCT Header Extension Types (EXT_FDT and EXT_CENC). 8.1. Registration of the FDT Instance XML Namespace IANA has registered the following new XML Namespace in the IETF XML "ns" registry [RFC3688] at http://www.iana.org/assignments/xml-registry/ns.html. Registration of the application/fdt+xml Media Type IANA has registered the following in the "Application Media Types" registry at http://www.iana.org/assignments/media-types/application/. Encoding considerations: binary (the FLUTE file delivery protocol does not impose any restriction on the objects it carries and in particular on the FDT Instance itself) Restrictions on usage: none 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: [RFC6726], especially noting 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 that use this media type: file and object delivery applications and protocols (e.g., FLUTE).Magic number(s): none File extension(s): ".fdt" (e.g., if there is a need to store an FDT Instance as a file) Macintosh File Type Code(s): none Person and email address to contact for further information: Toni Paila (toni.paila@gmail.com) Creation of the FLUTE Content Encoding Algorithms Registry IANA has created a new registry, "FLUTE Content Encoding Algorithms", with a reference to [RFC6726]; see Section 3.4.3. The registry entries consist of a numeric value from 0 to 255, inclusive, and may be registered using the Specification Required policy[START_REF] Narten | Guidelines for Writing an IANA Considerations Section in RFCs[END_REF].The initial contents of the registry are as follows, with unspecified values available for new registrations:

	RFC 6726 RFC 6726 RFC 6726	FLUTE FLUTE FLUTE	November 2012 November 2012 November 2012
	8. IANA Considerations This specification contains five separate items upon which IANA has taken action: Subtype name: fdt+xml Required parameters: none Optional parameters: charset="utf-8" Additional information: 1. XML: The XML Schema specified in Section 3.4.2 8.3. Type name: application 8.4.
	Intended usage: Common
	Author/Change controller: IETF
	Paila, et al. Paila, et al. Paila, et al.	Standards Track Standards Track Standards Track	[Page 33] [Page 34] [Page 35]

URI: urn:ietf:params:xml:ns:fdt Registrant Contact: Toni Paila (toni.paila@gmail.com) XML: N/A 8.2. Registration of the FDT Instance XML Schema IANA has registered the following in the IETF XML "schema" registry [RFC3688] at http://www.iana.org/assignments/xml-registry/schema.html. URI: urn:ietf:params:xml:schema:fdt Registrant Contact: Toni Paila (toni.paila@gmail.com)

* "FEC-OTI-FEC-Instance-ID" carries the "FEC Instance ID" Object Transmission Information element defined in [RFC5052] for Under-Specified FEC Schemes.

* "FEC-OTI-Maximum-Source-Block-Length" carries the "Maximum-Source-Block-Length" Object Transmission Information element defined in [RFC5052], if required by the FEC Scheme.

* "FEC-OTI-Encoding-Symbol-Length" carries the "Encoding-Symbol-Length" Object Transmission Information element defined in [RFC5052], if required by the FEC Scheme.

* "FEC-OTI-Max-Number-of-Encoding-Symbols" carries the "Max-Number-of-Encoding-Symbols" Object Transmission Information element defined in [RFC5052], if required by the FEC Scheme.

* "FEC-OTI-Scheme-Specific-Info" carries the "encoded Scheme-specific FEC Object Transmission Information" as defined in [RFC5052], if required by the FEC Scheme. Paila, et al. Standards Track [Page 25]

Object

Transmission Information element defined in [START_REF] Watson | Forward Error Correction (FEC) Building Block[END_REF].

* "FEC-OTI-FEC-Encoding-ID" carries the "FEC Encoding ID" Object Transmission Information element defined in [START_REF] Watson | Forward Error Correction (FEC) Building Block[END_REF], as carried in the Codepoint field of the ALC/LCT

Incremented the FLUTE protocol version from 1 to 2, due to concerns about backwards compatibility. For instance, the LCT header changed between RFC 3451 and [START_REF] Luby | Layered Coding Transport (LCT) Building Block[END_REF]. In RFC 3451, the T and R fields of the LCT header indicate the presence of Sender Current Time and Expected Residual Time, respectively. In [START_REF] Luby | Layered Coding Transport (LCT) Building Block[END_REF], these fields MUST be set to zero and MUST be ignored by receivers (instead, the EXT_TIME Header Extensions can convey this information if needed). Thus, [START_REF] Luby | Layered Coding Transport (LCT) Building Block[END_REF] is not backwards compatible with RFC 3451, even though both use LCT version 1. FLUTE version 1 as specified in [START_REF] Paila | FLUTE -File Delivery over Unidirectional Transport[END_REF] MUST use RFC 3451. FLUTE version 2 as specified in this document MUST use [START_REF] Luby | Layered Coding Transport (LCT) Building Block[END_REF]. Therefore, an implementation that relies on [START_REF] Paila | FLUTE -File Delivery over Unidirectional Transport[END_REF] and RFC 3451 will not be backwards compatible with FLUTE as specified in this document. Clarified what should be considered 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 Section 7.5 to define IPsec/ESP as a mandatory-to-implement security solution.

Removed the 'Statement of Intent' from Section 1. The statement of intent was meant to clarify the "Experimental" status of [START_REF] Paila | FLUTE -File Delivery over Unidirectional Transport[END_REF].

It does not apply to this document.

Added clarification of "XML-DSIG" near the end of Section 3.

In Section 3.2, replaced "complete FDT" with text that is more descriptive.

Clarified Figure 1 with regard to "Encoding Symbol(s) for FDT Instance".

Clarified the text regarding FDT Instance ID wraparound at the end of Section 3.4.1.

Clarified "complete FDT" in Section 3.4.2.

Added semantics for the case where two TOIs refer to the same Content-Location. It is now in line with the way that 3GPP and Digital Video Broadcasting (DVB) standards interpret this case.

In Section 3.4.2, the XML Schema of the FDT Instance was modified per advice from various sources. For example, extension by element was missing but is now supported. Also, the namespace definition was changed to URN format.

Clarified FDT-schema extensibility at the end of Section 3.4.2.

Paila, et al.

Standards Track [Page 38]

Appendix A. Receiver Operation (Informative) This section gives an example of 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 (source IP address, Transport Session Identifier) pair. 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, the 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. The receiver recovers an object. An object can be recovered when an appropriate set of packets containing Encoding Symbols for the transmission object has been received. An appropriate set of packets is dependent on the properties of the FEC Encoding ID and FEC Instance ID, and on other information contained in the FEC Object Transmission Information.

6. Objects with TOI = 0 are reserved for FDT Instances. All FDT Instances are signaled by including an EXT_FDT Header Extension in the LCT header. The EXT_FDT header contains an FDT Instance ID (i.e., an FDT version number). If the object has an FDT Instance ID 'N', the receiver parses the payload of the instance 'N' of the FDT and updates its FDT database accordingly.

7. If the object recovered is not an FDT Instance but a file, the receiver looks up its FDT database to get the properties described in the database, and assigns the file the given properties. The receiver also checks that the received content