RMT T. Paila Internet-Draft Nokia Expires: May 8, 2004 M. Luby Digital Fountain R. Lehtonen TeliaSonera V. Roca INRIA Rhone-Alpes R. Walsh Nokia November 8, 2003 FLUTE - File Delivery over Unidirectional Transport draft-ietf-rmt-flute-04.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 8, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. Paila, et al. Expires May 8, 2004 [Page 1] Internet-Draft FLUTE November 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . 3 3. File delivery . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 File delivery session . . . . . . . . . . . . . . . . . . . 5 3.2 File Delivery Table . . . . . . . . . . . . . . . . . . . . 6 3.3 Dynamics of FDT Instances within file delivery session . . . 7 3.4 Structure of FDT Instance . . . . . . . . . . . . . . . . . 8 3.4.1 Format of FDT Instance Header . . . . . . . . . . . . . . . 9 3.4.2 Syntax of FDT Instance Payload . . . . . . . . . . . . . . . 10 3.5 Multiplexing of files within a file delivery session . . . . 12 4. Channels, congestion control and timing . . . . . . . . . . 12 5. Delivering FEC Object Transmission Information . . . . . . . 13 5.1 Use of EXT_FTI for delivery of FEC Object Transmission Information . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.1 General EXT_FTI format . . . . . . . . . . . . . . . . . . . 14 5.1.2 FEC Encoding ID specific formats for EXT_FTI . . . . . . . . 15 5.2 Use of FDT for delivery of FEC Object Transmission Information . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Describing file delivery sessions . . . . . . . . . . . . . 19 7. Security considerations . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 Normative references . . . . . . . . . . . . . . . . . . . . 21 Informative references . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 A. Receiver operation (informative) . . . . . . . . . . . . . . 23 B. Example of FDT Instance Payload (informative) . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . 26 Paila, et al. Expires May 8, 2004 [Page 2] Internet-Draft FLUTE November 2003 1. Introduction This document defines FLUTE, a protocol for unidirectional delivery of files over the Internet. The specification builds on Asynchronous Layered Coding (ALC), version 1 [3], the base protocol designed for massively scalable multicast distribution. ALC defines transport of arbitrary binary objects. For file delivery applications mere transport of objects is not enough, however. The end systems need to know what do the objects actually represent. This document specifies a technique called FLUTE - a mechanism for signalling and mapping the properties of files to concepts of ALC in a way that allows receivers to assign those parameters for received objects. Consequently, throughout this document the term 'file' relates to an 'object' as discussed in ALC. Although this specification frequently makes use of multicast addressing as an example, the techniques are similarly applicable for use with unicast addressing. This specification answers the following questions: * How does an ALC session represent a file delivery session? * How can the properties of delivered files be signaled in-band within the file delivery session? * How to describe the file delivery session, its transport details and its schedule in a general case? * What is the internal structure of file delivery sessions wherein several files can be delivered within a single session? This specification is structured as follows. Chapter 3 begins by defining the concept of the file delivery session. Following that it introduces the File Delivery Table that forms the core part of this specification. Further, it discusses multiplexing issues of transport objects within a file delivery session. Chapter 4 describes the use of congestion control and channels with FLUTE. Chapter 5 defines how the FEC Object Transmission Information is to be delivered within a file delivery session. Chapter 6 defines the required parameters for describing file delivery sessions in a general case. Chapter 7 outlines security considerations regarding file delivery with FLUTE. Last, there are two informative appendixes. The first appendix gives an example of File Delivery Table. The second appendix describes an envisioned receiver operation for the receiver of the file delivery session. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Paila, et al. Expires May 8, 2004 [Page 3] Internet-Draft FLUTE November 2003 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. The terms "object" and "transport object" are consistent with the definitions in ALC [3] and LCT [4]. The terms "file" and "source object" are pseudonyms for "object". 3. File delivery Asynchronous Layered Coding [3] 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 "www.ex.com/docs/file.txt". Using the example, the following properties describe the properties that need to be conveyed by the file delivery protocol. * Location of the file, expressed as either absolute or relative URI. In the above example: "www.ex.com/docs/file.txt" * File name (usually, this can be concluded from the URI). In the above example: "file.txt" * File type, expressed as MIME media type (usually, this can also be concluded from the extension of the file name). In the above example: "text/plain" * File size, expressed in bytes. In the above example: "5200" * Content encoding of the file, within transport. In the above example, the file could be encoded using ZLIB [11]. In this case the size of the transport object carrying the file would probably differ from the file size. * Security properties of the file such as digital signatures, message digestives, etc. Paila, et al. Expires May 8, 2004 [Page 4] Internet-Draft FLUTE November 2003 3.1 File delivery session ALC is a protocol instantiation of Layered Coding Transport building block (LCT) [4]. Thus ALC inherits the session concept of LCT. In this document we will use concept ALC/LCT session to collectively denote the interchangeable terms ALC session and LCT session. An ALC/LCT session consists of a set of logically grouped ALC/LCT channels associated with a single sender sending packets with ALC/LCT headers for one or more objects. An ALC/LCT channel is defined by the combination of a sender and an address associated with the channel by the sender. A receiver joins a channel to start receiving the data packets sent to the channel by the sender, and a receiver leaves a channel to stop receiving data packets from the channel. One of the fields carried in the ALC/LCT header is the Transport Session Identifier (TSI). The TSI is scoped by the source IP address, and the (source IP address, TSI) pair uniquely identifies a session, i.e., the receiver uses this pair carried in each packet to uniquely identify from which session the packet was received. In case multiple objects are carried within a session another field within the ALC/LCT header, the Transport Object Identifier (TOI), identifies from which object within the session the data in the packet was generated. Note that each object is associated with a unique TOI within the scope of a session. When FLUTE is used for file delivery over ALC the following rules apply: * The ALC/LCT session is called file delivery session. * The ALC/LCT concept of 'object' denotes either a 'file' or a 'File Delivery Table Instance' (section 3.2) * The TOI field MUST be included in ALC packets sent within a FLUTE session, with the exception that ALC packets sent in a FLUTE session with the Close session (A) flag set to 1 (signaling the end of the session) and containing no payload MAY not include the TOI. See Section 5.1 of RFC 3451 [4] for the LCT definition of the Close session flag, and see Section 4.2 of RFC 3450 [3] for an example of its use within an ALC packet. * The TOI value '0' is reserved for delivery of File Delivery Table Instances * Each file in a file delivery session MUST be associated with a TOI (>0) in the scope of that session. Paila, et al. Expires May 8, 2004 [Page 5] Internet-Draft FLUTE November 2003 3.2 File Delivery Table The File Delivery Table (FDT) provides a means to describe various attributes associated with files that are to be delivered within the file delivery session. The following lists are examples of such attributes, and are not intended to be mutually exclusive. Attributes related to the delivery of file: - TOI value that represents the file - FEC Instance ID - FEC Object Transmission Information - Size of the transport object carrying the file - Aggregate rate of sending packets to all channels Attributes related to the file itself: - Name, Identification and Location of file (specified by the URI) - MIME media type of file - Size of file - Encoding of file - Message digest of file 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 indicating the location of the file. The TOI is included in each ALC/LCT data packet during the delivery of the file, and thus the TOI carried in the file description entry is how the receiver determines which ALC/LCT data packets contain information about which file. Each file description entry may also contain one or more descriptors that map the above-mentioned attributes to the file. Each file delivery session MUST have an FDT that is local to the given session. The FDT SHOULD provide a file description entry mapped to a TOI for each file appearing within the session. Handling of unmapped TOIs (those that are not resolved by the FDT) is out of Paila, et al. Expires May 8, 2004 [Page 6] Internet-Draft FLUTE November 2003 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, or complement any other FDT Instance. A certain FDT Instance may be repeated several times during a session, even after subsequent FDT Instances (with higher FDT Instance ID numbers) have been transmitted. In minimum the FDT Instance contains a single file description entry. In maximum the FDT Instance contains the complete FDT of the file delivery session. A receiver of the file delivery session keeps an FDT database for received file description entries. The receiver maintains the database, for example, upon reception of FDT Instances. Thus, at any given time the contents of the FDT database represent the receiver's current view of the FDT of the file delivery session. Since each receiver behaves independently of other receivers, it SHOULD NOT be assumed that the contents of the FDT database are the same for all the receivers of a given file delivery session. Since FDT database is an abstract concept, the structure and the maintaining of the FDT database are left to individual implementations and are thus out of scope of this specification. 3.3 Dynamics of FDT Instances within file delivery session 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. In minimum, a file description entry contains the mapping to TOI and the URI. * An FDT Instance MAY appear in any part of the file delivery session and even multiplexed with other files or other FDT Instances. * The TOI value of '0' MUST be reserved for delivery of FDT Instances. The use of other TOI values for FDT Instances is outside the scope of this specification. * FDT Instance is identified by the use of a new fixed length LCT Header Extension EXT_FDT (defined later in this chapter). Each FDT Instance is uniquely identified within the file delivery session by its FDT Instance ID. Any ALC/LCT packet carrying FDT Instance (indicated by TOI = 0) MUST include EXT_FDT. Paila, et al. Expires May 8, 2004 [Page 7] Internet-Draft FLUTE November 2003 * It is RECOMMENDED that FDT Instance that contains the file description entry for a file is sent prior to the sending of the described file within a file delivery session. * Within a file delivery session, any TOI MAY be described more than once. An example: previous FDT Instance 0 describes TOI of value '3'. Now, subsequent FDT Instances can either keep TOI '3' unmodified on the table, not to include it or complement the description. * An FDT Instance is valid until its expiration time. The expiration time is expressed within the FDT Instance payload as a 32 bit data field. The value of the data field represents the 32 most significant bits of a 64 bit Network Time Protocol (NTP) [6] time value. Wrap-around of the 32 bit time is to be handled according to NTP. * The receiver behaviour upon expiration of the FDT Instance is out of scope of this specification. * A sender MUST use an expiry time in the future upon creation of an FDT Instance. * Any FEC Encoding ID MAY be used for the sending of FDT Instances. The default is to use FEC Encoding ID 0 for the sending of FDT Instances. (Note that since FEC Encoding ID 0 is the default for FLUTE, this implies that Source Block Number and Encoding Symbol ID lengths both default to 16 bytes each.) 3.4 Structure of FDT Instance The FDT Instance consists of two parts: FDT Instance Header and FDT Instance Payload. The FDT Instance Header is a new fixed length LCT Header extension (EXT_FDT). It contains the FDT Instance ID that uniquely identifies FDT instances within a file delivery session. The FDT Instance Header is placed in the same way as any other LCT extension header. There MAY be other LCT extension headers in use. The LCT extension headers are followed by the FEC Payload ID, and finally the Encoding Symbols for the FDT Instance Payload which contains one or more file description entries. The FDT Instance Payload MAY span over several ALC packets - the number of ALC packets is indicated by the FEC Object Transmission Information associated to this FDT Instance. The FDT Instance Header is carried in each ALC packet carrying FDT Instance. The FDT Instance Header is identical for all the ALC/LCT packets carrying parts of a particular FDT Instance. Paila, et al. Expires May 8, 2004 [Page 8] Internet-Draft FLUTE November 2003 The overall format of ALC/LCT packets carrying FDT Instance is depicted in the Figure 1 below. As defined in [3], all ALC/LCT packets are sent using UDP. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP header | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Default LCT header (with TOI = 0) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LCT header extensions (EXT_FDT, EXT_FTI, etc.) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Payload ID | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoding Symbol(s) of FDT Instance Payload | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - Overall FDT Packet 3.4.1 Format of FDT Instance Header FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI specific LCT header extension [4]. The Header Extension Type (HET) for the extension is 192. Its format is defined below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET = 192 | FDT Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FDT Instance ID, 24 bits: For each file delivery session the numbering of FDT Instances starts from '0' and is incremented by exactly one for each subsequent FDT Instance. After reaching the maximum value (2^24-1), the numbering starts again from '0'. When wraparound from 2^24-1 to 0 occurs, 0 is considered higher than 2^24-1. Receiver handling of wraparound and other special situations (for example, missing FDT Instance IDs Paila, et al. Expires May 8, 2004 [Page 9] Internet-Draft FLUTE November 2003 resulting in longer increments than one) is left out of this specification to individual implementations of FLUTE. 3.4.2 Syntax of FDT Instance Payload The FDT Instance Payload contains file description entries that provide the mapping functionality described in 3.2 above. The FDT Instance Payload is an XML structure that has a single root element "FDT-Payload". The "FDT-Payload" element MUST contain "Expires" attribute, which tells the expiry time of the FDT Instance Payload. In addition, the "FDT-Payload" element MAY contain "Complete" attribute (boolean), which MAY be used to signal that the given FDT Instance is the last FDT Instance to be expected on this file delivery session. For each file to be declared in the given FDT Instance there is a single file description entry in the FDT Instance Payload. Each entry is represented by element "File" which is a child element of the FDT Payload structure. The attributes of "File" element in the XML structure represent the attributes given to the file that is delivered in the file delivery session. Each "File" element MUST contain at least two attributes "TOI" and "Content-Location". "TOI" MUST be assigned a valid TOI value as described in section 3.3 above. "Content-Location" MUST be assigned a valid URI as defined in [7]. In addition to mandatory attributes, the "File" entity MAY contain other attributes of which the following are specifically pointed out. * If the MIME type of the file is described, attribute "Content-Type" MUST be used for the purpose as defined in [7]. * If the length of the file is described, attribute "Content-Length" MUST be used for the purpose as defined in [7]. If the length of the file is different than the length of the transport object that carries it (the file was content encoded before transport), another attribute "Transfer-Length" MAY be used. The attribute "Transfer-Length" specifies the size of the transport object in bytes. * If the content encoding scheme of the file is described, attribute "Content-Encoding" MUST be used for the purpose as defined in [7]. * If the MD5 message digest of the file is described, attribute "Content-MD5" MUST be used for the purpose as defined in [7]. Paila, et al. Expires May 8, 2004 [Page 10] Internet-Draft FLUTE November 2003 * The FEC Object Transmission Information attributes as described in section 5.2. The following specifies the XML Schema [9][10] for FDT Instance Payload: Paila, et al. Expires May 8, 2004 [Page 11] Internet-Draft FLUTE November 2003 Any XML document that conforms with the above XML Schema is a valid FDT. 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, those MUST be placed within the attributes of the element "File". It is RECOMMENDED that the new descriptors applied in the FDT are in the format of MIME fields and are either defined in HTTP/1.1 specification [7] or otherwise well-known specification. 3.5 Multiplexing of files within a file delivery session The delivered files are carried as transport objects (identified with TOIs) in the file delivery session. All these objects, including the FDT Instances, MAY be multiplexed in any order and in parallel with each other. Especially multiple FDT Instances MAY be delivered during the session in a particular TOI. In this case, it is RECOMMENDED that the sending of a previous FDT Instance SHOULD end before the sending of the next FDT Instance starts. However, due to unexpected network conditions the FDT Instances MAY be multiplexed packetwise. In that case, the FDT Instances are uniquely identified by their FDT Instance ID carried in the EXT_FDT headers. 4. Channels, congestion control and timing ALC/LCT has a concept of channels and congestion control. There are four scenarios FLUTE is envisioned to be applied. (a) Use a single channel and a single-rate congestion control protocol. (b) Use multiple channels and a multiple-rate congestion control protocol. In this case the FDT Instances MAY be delivered on more than one channel. (c) Use a single channel without congestion control supplied by ALC, but only when in a controlled network environment where flow/ congestion control is being provided by other means. (d) Use multiple channels without congestion control supplied by ALC, but only when in a controlled network environment where flow/ congestion control is being provided by other means. In this case the FDT Instances MAY be delivered on more than one channel. Paila, et al. Expires May 8, 2004 [Page 12] Internet-Draft FLUTE November 2003 When using just one channel for a file delivery session, as in (a) and (c), the notion of 'prior' and 'after' are intuitively defined for the delivery of objects with respect to their delivery times. However, if multiple channels are used, as in (b) and (d), it is not straightforward to state that an object was delivered 'prior' to the other. An object may begin to be delivered on one or more of those channels before the delivery of a second object begins. However, the use of multiple channels/layers may complete the delivery of the second object before the first. This is not a problem when objects are delivered sequentially using a single channel. Thus, if the application of FLUTE has a mandatory or critical requirement that the first transport object must complete 'prior' to the second one, it is RECOMMENDED that only a single channel is used for the file delivery session. 5. Delivering FEC Object Transmission Information FLUTE inherits the use of FEC building block [5] from ALC. When using FLUTE for file delivery over ALC the FEC Object Transmission Information MUST be delivered in-band within the file delivery session. In this chapter, two methods are specified for FLUTE for this purpose: the use of ALC specific LCT extension header EXT_FTI [3], and, the use of FDT. The receiver of file delivery session MUST support delivery of FEC Object Transmission Information using the EXT_FTI for the FDT Instances carried using TOI value 0. For the TOI values other than 0 the receiver MUST support both methods: the use of EXT_FTI and the use of FDT. The FEC Object Transmission Information that needs to be delivered to receivers MUST be exactly the same whether it is delivered using EXT_FTI or using FDT (or both). Section 5.1 describes the required FEC Object Transmission Information that MUST be delivered to receivers for various FEC Encoding IDs. In addition, it describes the delivery using EXT_FTI. Section 5.2 describes the delivery using FDT. The FEC Object Transmission Information regarding a given TOI may be available from several sources. In this case, it is RECOMMENDED that the receiver of the file delivery session prioritizes the sources in the following way (in the order of decreasing priority). 1. FEC Object Transmission Information that is available in EXT_FTI. 2. FEC Object Transmission Information that is available in the FDT. Paila, et al. Expires May 8, 2004 [Page 13] Internet-Draft FLUTE November 2003 3. FEC Object Transmission Information that is available out of band. 5.1 Use of EXT_FTI for delivery of FEC Object Transmission Information As specified in [3], the EXT_FTI header extension is intended to carry in band the FEC Object Transmission Information for an object. It is left up to individual implementations to decide how frequently and in which ALC packets the EXT_FTI header extension occurs. However, EXT_FTI MUST be sent at least in one ALC packet belonging to TOI 0. The ALC specification does not define the format or the processing of the EXT_FTI header extension. The following sections specify EXT_FTI when used in FLUTE. In FLUTE, the FEC Encoding ID (8 bits) is carried in the Codepoint field of the ALC/LCT header. 5.1.1 General EXT_FTI format The general EXT_FTI format specifies the structure and those attributes of FEC Object Transmission Information that are applicable to any FEC Encoding ID. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET = 64 | HEL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Transfer Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Instance ID | FEC Enc. ID Specific Format | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header Extension Type (HET), 8 bits: 64 as defined in [3] Header Extension Length (HEL), 8 bits: The length of the whole Header Extension field, expressed in multiples of 32-bit words. This length includes the FEC Encoding ID specific format part. Transfer Length, 48 bits: Paila, et al. Expires May 8, 2004 [Page 14] Internet-Draft FLUTE November 2003 The length of the transport object that carries the file in bytes. (This is the same as the file length if the file is not content encoded.) FEC Instance ID, optional, 16 bits: This field is used for FEC Instance ID. It is only present if the value of FEC Encoding ID is in the range of 128-255. When the value of FEC Encoding ID is in the range of 0-127, this field is set to 0. FEC Encoding ID Specific Format: Different FEC encoding schemes will need different sets of encoding parameters. Thus, the structure and length of this field depends on FEC Encoding ID. The next sections specify structure of this field for FEC Encoding ID numbers 0, 128, 129 and 130. 5.1.2 FEC Encoding ID specific formats for EXT_FTI 5.1.2.1 FEC Encoding IDs 0, 128, and 130 FEC Encoding ID 0 is 'Compact No-Code FEC' (Fully-Specified) [8]. FEC Encoding ID 128 is 'Small Block, Large Block and Expandable FEC' (Under-Specified) [5]. FEC Encoding ID 130 is 'Compact FEC' (Under-Specified) [8]. For these FEC Encoding IDs, the FEC Encoding ID specific format of EXT_FTI is defined as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ General EXT_FTI format | Encoding Symbol Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Source Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Encoding Symbol Length, 16 bits: Length of encoding symbol in bytes. All encoding symbols of a transport object MUST be equal to this length, with the optional exception of the last source symbol of the last source block (so that redundant padding is not mandatory in this last symbol). This last source symbol MUST be logically padded out with zeroes when another encoding symbol is computed based on this source symbol to ensure the same interpretation of this encoding symbol value by the sender and receiver. However, this padding need not be actually sent with the data of the last source symbol. Paila, et al. Expires May 8, 2004 [Page 15] Internet-Draft FLUTE November 2003 Maximum Source Block Length, 32 bits The maximum number of source symbols per source block. This EXT_FTI specification requires that an algorithm is known to both sender and receivers for determining the size of all source blocks of the transport object that carries the file identified by the TOI (or within the FDT Instance identified by the TOI and the FDT Instance ID). The algorithm SHOULD be the same for all files using the same FEC Encoding ID within a session. Section 5.1.2.3 describes an algorithm that is RECOMMENDED for this use. For the FEC Encoding IDs 0, 128 and 130, this algorithm is the only well known way the receiver can determine the length of each source block. Thus, the algorithm does two things: (a) it tells the receiver the length of each particular source block as it is receiving packets for that source block - this is essential to all of these FEC schemes; and, (b) it provides the source block structure immediately to the receiver so that the receiver can determine where to save recovered source blocks at the beginning - this is an optimization which is essential for some implementations. 5.1.2.2 FEC Encoding ID 129 Small Block Systematic FEC (Under-Specified). The FEC Encoding ID specific format of EXT_FTI is defined as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ General EXT_FTI format | Encoding Symbol Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Source Block Length | Max. Num. of Encoding Symbols | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Encoding Symbol Length, 16 bits: Length of encoding symbol in bytes. Maximum Source Block Length, 16 bits: The maximum number of source symbols per source block. Maximum Number of Encoding Symbols, 16 bits: Maximum number of encoding symbols that can be generated for a source Paila, et al. Expires May 8, 2004 [Page 16] Internet-Draft FLUTE November 2003 block. All encoding symbols of a transport object MUST be equal to this length, with the optional exception of the last source symbol of the last source block (so that redundant padding is not mandatory in this last symbol). This last source symbol MUST be logically padded out with zeroes when another encoding symbol is computed based on this source symbol to ensure the same interpretation of this encoding symbol value by the sender and receiver. However, this padding need not be actually sent with the data of the last source symbol. This EXT_FTI specification requires that an algorithm is known to both sender and receivers for determining the size of all source blocks of the transport object that carries the file identified by the TOI (or within the FDT Instance identified by the TOI and the FDT Instance ID). The algorithm SHOULD be the same for all files using the same FEC Encoding ID within a session. Section 5.1.2.3 describes an algorithm that is RECOMMENDED for this use. For FEC Encoding ID 129 the FEC Payload ID in each data packet already contains the source block length for the source block corresponding to the encoding symbol carried in the data packet. Thus, the algorithm for computing source blocks for FEC Encoding ID 129 could be to just use the source block lengths carried in data packets within the FEC Payload ID. However, the algorithm described in Section 5.1.2.3 is useful for the receiver to compute the source block structure at the beginning of the reception of data packets for the file. If the algorithm described in Section 5.1.2.3 is used then it MUST be the case that the source block lengths that appear in data packets agree with the source block lengths calculated by the algorithm. 5.1.2.3 Algorithm for Computing Source Block Structure This algorithm computes a source block structure so that all source blocks are as close to being equal length as possible. A first number of source blocks are of the same larger length, and the remaining second number of source blocks are sent of the same smaller length. The total number of source blocks (N), the first number of source blocks (I), the second number of source blocks (N-I), the larger length (A_large) and the smaller length (A_small) are calculated thus, Inputs: B -- Maximum Source Block length, i.e., the maximum number of source symbols per source block L -- Transfer length in bytes E -- Encoding Symbol Length in bytes Paila, et al. Expires May 8, 2004 [Page 17] Internet-Draft FLUTE November 2003 Output: N -- The number of source blocks into which the transport object is partitioned. The number and lengths of source symbols in each of the N source blocks. Algorithm: (a) The number of source symbols in the transport object is computed as T = L/E rounded up to the nearest integer. (b) The transport object is partitioned into N source blocks, where N = T/B rounded up to the nearest integer (c) The average length of a source block, A = T/N (this may be non-integer) (d) A_large = A rounded up to the nearest integer (it will always be the case that the value of A_large is at most B) (e) A_small = A rounded down to the nearest integer (if A is an integer A_small = A_large, and otherwise A_small = A_large - 1) (f) The fractional part of A, A_fraction = A - A_small (g) I = A_fraction * N (I is an integer between 0 and N-1) (h) Each of the first I source blocks consists of A_large source symbols, each source symbol is E bytes in length. Each of the remaining N-I source blocks consist of A_small source symbols, each source symbol is E bytes in length except that the last source symbol of the last source block is L-(((L-1)/E) rounded down to the nearest integer)*E bytes in length. 5.2 Use of FDT for delivery of FEC Object Transmission Information The FDT delivers FEC Object Transmission Information for each file using an appropriate attribute within the "File" element of the FDT structure. For future FEC Encoding IDs, if the attributes listed below do not fulfil the needs of describing the FEC Object Transmission Information then additional new attributes MAY be used. * "Transfer-Length" is semantically equivalent with the field "Transfer Length" of EXT_FTI. * "FEC-OTI-FEC-Instance-ID" is semantically equivalent with the field "FEC Instance ID" of EXT_FTI. * "FEC-OTI-Maximum-Source-Block-Length" is semantically equivalent with the field "Maximum Source Block Length" of EXT_FTI for FEC Encoding IDs 0, 128 and 130, and semantically equivalent with the field "Maximum Source Block Length" of EXT_FTI for FEC Encoding ID 129. Paila, et al. Expires May 8, 2004 [Page 18] Internet-Draft FLUTE November 2003 * "FEC-OTI-Encoding-Symbol-Length" is semantically equivalent with the field "Encoding Symbol Length" of EXT_FTI for FEC Encoding IDs 0, 128, 129 and 130. * "FEC-OTI-Max-Number-of-Encoding-Symbols" is semantically equivalent with the field "Maximum Number of Encoding Symbols" of EXT_FTI for FEC Encoding ID 129. 6. Describing file delivery sessions To start receiving a file delivery session, the receiver needs to know transport parameters associated with the session. Interpreting these parameters and starting the reception therefore represents the entry point from which thereafter the receiver operation falls into the scope of this specification. According to [3], the transport parameters of an ALC/LCT session that the receiver needs to know are: * The sender IP address; * The number of channels in the session; * The destination IP address and port number for each channel in the session; * The Transport Session Identifier (TSI) of the session; * An indication of whether or not the session carries packets for more than one object; Optionally, the following parameters MAY be associated with the session (Note, the list is not exhaustive): * The start time and end time of the session; * FEC Encoding ID and FEC Instance ID when the default FEC Encoding ID 0 is not used for the delivery of FDT; * Compression format if optional compression of FDT Instance Payload is used; * The FEC Object Transmission Information when this information is neither available in the EXT_FTI nor FDT as described in section 5. * Some information that tells receiver, in the first place, that the session contains files that are of interest Paila, et al. Expires May 8, 2004 [Page 19] Internet-Draft FLUTE November 2003 How the receiver acquires the above-mentioned parameters is out of scope of this document. The specification, in particular, does not mandate or exclude any mechanism. The description can be conveyed to the receiver via techniques such as Session Announcement Protocol [12], email, accessing URL, manual configuration, etc. Similarly the format of this session description is out of the scope of this document. 7. Security considerations There is a risk of forged file delivery sessions. A malicious attacker may spoof file delivery (ALC/LCT) packets in order to initiate an attack. The attacker may have several objectives he or she wishes to achieve, like Denial of Service (DoS). The following are the most obvious risks, however not exhaustive. The attacker can focus on the FDT information, sending forged packets with erroneous FDT-Payload fields. Many attacks can follow this approach. For instance a malicious attacker may alter the Content-Location field of TOI 'n', to make it point to a system file or a user configuration file. Then, TOI 'n' can carry a Trojan horse or some other type of virus. Another example is generating a bad Content-MD5 sum, leading receivers to reject the associated file that will be declared corrupted. The Content-Encoding can also be modified, which also prevents the receivers to correctly handle the associated file. These examples show that the FDT information is critical to the FLUTE delivery service. It is therefore highly RECOMMENDED that the FDT information be protected by the appropriate security measures. For instance TESLA [14] can be used for authenticating the FDT source, along with the other packets exchanged during the ALC/LCT session. In some cases a group authentication service can be sufficient. In that case, simple and efficient cryptographic transforms can then be used [13]. The FDT content may also be digitally signed, which provides both source authentication and packet integrity. This is feasible if the FDT packet rate is kept sufficiently low (generating/verifying digital signatures are computationally demanding tasks). In that case, the number of signature verifications at a receiver should be rate limited in order to prevent DoS attacks consisting in sending a high number of forged FDT packets. Finally it is RECOMMENDED that the FLUTE delivery service does not have write access to the system files or directories, or any other critical areas. An attacker can also eavesdrop on the FLUTE session. Packets containing the FDT information are critical from that point of view since they contain information on the session content. When this is an issue it is RECOMMENDED that the FDT packets be encrypted (as well Paila, et al. Expires May 8, 2004 [Page 20] Internet-Draft FLUTE November 2003 as the data packets) using a confidentiality service. The MSEC IETF Working Group defines security transforms, Group Key Management and Group Security Associations building blocks that can be used to that purpose. A difficulty is the unidirectional feature of FLUTE. Many protocols providing application-level security are based on bidirectional communications. The application of these security protocols in case of strictly unidirectional links is not considered in the present document. In addition to the attacks on the FDT information, FLUTE is subject to attacks on the ALC/LCT session itself. Therefore, the security considerations of [3] and [4] also apply to FLUTE. 8. Acknowledgements The following persons have contributed to this specification: Juha-Pekka Luoma, Esa Jalonen, Sami Peltotalo, Jani Peltotalo, Brian Adamson and Topi Pohjolainen. The authors would like to thank all the contributors for their valuable work in reviewing and providing feedback regarding this specification. Normative references [1] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [3] Luby, M., Gemmel, J., Vicisano, L., Rizzo, L. and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002. [4] Luby, M., Gemmel, J., Vicisano, L., Rizzo, L., Handley, M. and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002. [5] Luby, M., Gemmel, J., Vicisano, L., Rizzo, L., Handley, M. and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002. [6] Mills, D., "Network Time Protocol (Version 3), Specification, Implementation and Analysis", RFC 1305, March 1992. [7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- Paila, et al. Expires May 8, 2004 [Page 21] Internet-Draft FLUTE November 2003 HTTP/1.1", RFC 2616, June 1999. [8] Luby, M. and L. Vicisano, "Compact Forward Error Correction (FEC) Schemes", draft-ietf-rmt-bb-fec-supp-compact-01 (work in progress), May 2003. [9] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C Recommendation, May 2001. [10] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C Recommendation, May 2001. Informative references [11] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996. [12] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. [13] Hardjono, T. and B. Weis, "The Multicast Security Architecture", draft-ietf-msec-arch-01 (work in progress), May 2003. [14] Perrig, A., Canetti, R., Song, D., Tygar, D. and B. Briscoe, "TESLA: Multicast Source Authentication Transform Introduction", draft-ietf-msec-tesla-intro-01 (work in progress), October 2002. Authors' Addresses Toni Paila Nokia Itamerenkatu 11-13 Helsinki FIN-00180 Finland EMail: toni.paila@nokia.com Paila, et al. Expires May 8, 2004 [Page 22] Internet-Draft FLUTE November 2003 Michael Luby Digital Fountain 39141 Civic Center Dr. Suite 300 Fremont, CA 94538 USA EMail: luby@digitalfountain.com Rami Lehtonen TeliaSonera Hatanpaan valtatie 18 Tampere FIN-33100 Finland EMail: rami.lehtonen@teliasonera.com Vincent Roca INRIA Rhone-Alpes 655, av. de l'Europe Montbonnot St Ismier cedex 38334 France EMail: vincent.roca@inrialpes.fr Rod Walsh Nokia Visiokatu 1 Tampere FIN-33720 Finland EMail: rod.walsh@nokia.com Appendix A. Receiver operation (informative) This chapter gives an example how the receiver of the file delivery session may operate. Instead of a detailed state-by-state specification the following should be interpreted as a rough sequence of an envisioned file delivery receiver. 1. The receiver obtains the description of the file delivery session identified by the pair: (source IP address, Transport Session Identifier). The receiver also obtains the destination IP addresses and respective ports associated with the file delivery Paila, et al. Expires May 8, 2004 [Page 23] Internet-Draft FLUTE November 2003 session. 2. The receiver joins the channels in order to receive packets associated with the file delivery session. The receiver may schedule this join operation utilizing the timing information contained in a possible description of the file delivery session. 3. The receiver receives ALC/LCT packets associated with the file delivery session. The receiver checks that the packets match the declared Transport Session Identifier. If not, packets are silently discarded. 4. While receiving, the receiver demultiplexes packets based on their TOI and stores the relevant packet information in an appropriate area for recovery of the corresponding file. Multiple files can be reconstructed concurrently. 5. Receiver recovers an object. An object can be recovered when an appropriate set of packets containing encoding symbols for the transport object have been received. An appropriate set of packets is dependent on the properties of the FEC Encoding ID and FEC Instance ID, and on other information contained in the FEC Object Transmission Information. 6. If the recovered object was an FDT instance with FDT Instance ID 'N', the receiver parses the payload of the instance 'N' of FDT and updates its FDT database accordingly. The receiver identifies FDT instances within a file delivery session by the EXT_FDT header extension. Any object that is delivered using EXT_FDT header extension is an FDT instance, uniquely identified by the FDT Instance ID. Note that TOI '0' is exclusively reserved for FDT delivery. 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 file with the given properties. The receiver also checks that received content length matches with the description in the database. Optionally, if MD5 checksum has been used, the receiver checks that calculated MD5 matches with the description in the FDT database. 8. The actions the receiver takes with imperfectly received files (missing data, mismatching digestive, etc.) is outside the scope of this specification. When a file is recovered before the associated file description entry is available, a possible behavior is to wait until an FDT Instance is received that includes the missing properties. Paila, et al. Expires May 8, 2004 [Page 24] Internet-Draft FLUTE November 2003 9. If the file delivery session end time has not been reached go back to 3. Otherwise end. Appendix B. Example of FDT Instance Payload (informative) Paila, et al. Expires May 8, 2004 [Page 25] Internet-Draft FLUTE November 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Paila, et al. Expires May 8, 2004 [Page 26] Internet-Draft FLUTE November 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Paila, et al. Expires May 8, 2004 [Page 27]