RMT C. Neumann Internet-Draft V. Roca Expires: April 20, 2006 INRIA Rhone-Alpes R. Walsh Nokia October 17, 2005 A File Aggregation Scheme for FLUTE draft-neumann-rmt-flute-file-aggregation-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 April 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document introduces a logical and physical file aggregation scheme for File Delivery over Unidirectional Transport (FLUTE). The logical file aggregation mechanism is a generalized grouping mechanism, allowing to logically group files. The physical file aggregation scheme allows, additionally to a logical grouping, to more efficiently use Forward Error Correction (FEC) in the context of Neumann, et al. Expires April 20, 2006 [Page 1] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 FLUTE, in particular when dealing with a large number of "small" files. Unlike a solution based on the creation of an archive, the object aggregation scheme (1) avoids the need to perform preliminary transformations on the content and (2) preserves the possibility to extract a subset of the content, which may be critical aspect with some partially reliable broadcasting test cases. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1 Logical aggregation . . . . . . . . . . . . . . . . . 4 1.1.2 Physical aggregation . . . . . . . . . . . . . . . . . 4 1.1.3 Aggregation Mode Selection . . . . . . . . . . . . . . 6 1.2 Modifications compared to the FLUTE version 1 specifications . . . . . . . . . . . . . . . . . . . . . . 6 2. Conventions used in this document . . . . . . . . . . . . . . 8 3. The Generalized Grouping Mechanism . . . . . . . . . . . . . . 9 3.1 Syntax of FDT Instance with the Generalized Grouping Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 A simple example . . . . . . . . . . . . . . . . . . . . . 9 4. The Physical File Aggregation Scheme . . . . . . . . . . . . . 11 4.1 multipart/mixed MIME type object and multipart/related MIME type object . . . . . . . . . . . . . . . . . . . . . 11 4.2 Extending the FDT with Aggregated Object Information . . . 11 4.3 Syntax of FDT Instance with Aggregated Object Description Information . . . . . . . . . . . . . . . . . 12 4.4 Symbol alignment of aggregated files . . . . . . . . . . . 17 4.4.1 MIME compatible padding . . . . . . . . . . . . . . . 17 4.5 Recovering files at FLUTE receiver supporting physical file aggregation . . . . . . . . . . . . . . . . . . . . . 17 4.5.1 Recovering files before the entire reception of the aggregated object . . . . . . . . . . . . . . . . 17 4.5.2 Recovering files after the entire reception of the aggregated object . . . . . . . . . . . . . . . . . . 18 4.6 Recovering files at FLUTE receiver that does not support physical file aggregation . . . . . . . . . . . . 18 4.7 Limitations . . . . . . . . . . . . . . . . . . . . . . . 19 5. FLUTE version 1 backward compatibility . . . . . . . . . . . . 20 5.1 Redirection mechanism . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1 Normative References . . . . . . . . . . . . . . . . . . . 24 9.2 Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 A. Example of FDT Instance (informative) . . . . . . . . . . . . 26 Neumann, et al. Expires April 20, 2006 [Page 2] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 B. Example of FDT Instance (informative) . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . 28 Neumann, et al. Expires April 20, 2006 [Page 3] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 1. Introduction 1.1 Motivations This document introduces a logical and physical file aggregation scheme for File Delivery over Unidirectional Transport (FLUTE) [10], version 1. FLUTE is a protocol for unidirectional delivery of files and builds on Asynchronous Layered Coding (ALC), version 1 [7], the base protocol designed for massively scalable multicast distribution. The logical object aggregation mechanism allows to logically group correlated files. The physical object aggregation scheme additionally allows to more efficiently use Forward Error Correction (FEC) with FLUTE in some situations. 1.1.1 Logical aggregation The logical aggregation mechanism offers a means to logically group files without physically binding them to the same transport object. This is achieved by labeling files as being part of one or more groups. This functionality is desirable when transmitting a set of closely related files that will be used by the receiver in the conjunction with each other. The effect is to simplify the FLUTE-to- application messaging and processing overhead and to enable selective caching of files when it is not feasible to either promiscuously receive all files or explicitly indicate all wanted files in advance of joining the FLUTE session. One example is an html page (file) with several embedded images. By labeling the web page file and all related image files as being part of the same group, the FLUTE receiver knows in advance the files he needs to download based on only the URI of the web page file. Without this grouping mechanism it would have to analyze the web page file and then deduce which other files are related and need to be downloaded. 1.1.2 Physical aggregation The main idea of the physical file aggregation scheme is to aggregate a (possibly large) set of (possibly small) files into one large aggregated object, that is treated as a single transport object by ALC. The benefits of logical aggregation, described above, also apply to physical aggregation. However, a shared-fate model is introduced as the successful reception of one of the aggregated files is to some extent statistically correlated to the successful reception of one or more others. Thus, there is a strong incentive to only physically aggregate files that are logically related into the same aggregated transport object. Neumann, et al. Expires April 20, 2006 [Page 4] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 The physical file aggregation scheme is made possible by simple extension to FLUTE FDTs which provides a dedicated signaling mechanism, enabling extended FLUTE receivers to extract the files within the large aggregated object. With physical aggregation, FEC encoding is performed on a large object rather than on each individual file, which can be highly beneficial for transmission performance. Therefore this technique offers two specific transmission performance improvements: 1. the coupon collector problem [14], that is caused by the separate FEC encoding of each individual file when file aggregation is not used, is now significantly reduced or even totally eliminated. Now FEC encoding is done over a single object, whose size is perhaps inferior to the maximum block size permitted by the FEC instance used (this is especially true with a Large Block FEC code). 2. large block FEC codes perform better on large blocks than on small blocks, and using file aggregation offers more opportunities to use such codes whose performance is significantly higher than Reed Solomon codes [13]. The performance gain of these two aspects depends on several parameters such as the FEC instance used, the aggregated object size and the number of files. Detailed quantitative analysis and explanation of the impact of all these parameters is outside the scope of this document. The physical file aggregation is mainly applicable for small files. The specified physical object aggregation solution is significantly different from a solution that would create a single archive from the list of files (e.g. a gzip compressed tarball archive). With an archive the result is either the full reconstruction of all individual files (if enough packets have been received for decoding to complete at a receiver) or an hazardous result (since the archive will be corrupted, possibly damaging the archive headers which then prevents file extraction). Indeed, although FEC can counter the effects of packet erasures, if the number of packets received is too low for the FEC decoding process to finish, the received parity packets may turn out to be inconsequential. On the opposite, the specified physical object aggregation solution can offer a partial reliability service, i.e. it enables a receiver to reconstruct parts of the content even if the FEC decoding process has not finished. To that purpose, the physical file aggregation scheme can optionally preserve the possibility to decode and exploit a subset of the content, by informing the receivers of the size and position of individual files within the aggregated object. Neumann, et al. Expires April 20, 2006 [Page 5] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 Another motivation for having an object aggregation scheme compared to a basic archive based solution (e.g. tarball), is that no extra transformation (i.e. archive creation or extraction) is required at either the FLUTE sender or receiver. Everything is managed automatically by the transport mechanism according to transport- specific optimizations and can be transparent to upper applications (i.e. built on top of FLUTE), or enhanced by application hints on file relationships, without breaking the basic semantics of FLUTE sessions. 1.1.3 Aggregation Mode Selection The selection of whether a set of files would benefit from either no aggregation, logical aggregation or physical aggregation must be made for (or by) the FLUTE sender. The merits of aggregation (Section 1.1.1 and Section 1.1.2), as well as the introduced receiver and sender complexities may be taken into account. In particular, the choice between logical and physical aggregation would be mostly application-specific and dependent on the file size distribution and the inter-file relationship (in receiver use). It would also be tuned to the anticipated end-to-end losses and any selected FEC instance. 1.2 Modifications compared to the FLUTE version 1 specifications This document describes a simple and light extension of the FLUTE in- band signaling, the File Delivery Table (FDT), which is used to identify the group to which each file belongs to and to inform each receiver about the properties and structure of the aggregated object. More precisely: 1. The FDT Instance syntax is extended introducing two new elements, "Group" and "aggregatedFile". 2. Additional information concerning the description of the aggregated object is added to the FDT. 3. An extra redirection to "extended" FDT Instances is introduced to be backward compatible with FLUTE version 1 specifications. This enables the use of FLUTE version 1 FDT Instance specifications in combination with the element-extended enhanced FDT schema of this specification. These modifications are described in details in Section 3 and Section 4 . All other features, requirements and specifications of the FLUTE Neumann, et al. Expires April 20, 2006 [Page 6] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 version 1 specification remain valid. Neumann, et al. Expires April 20, 2006 [Page 7] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. The terms "object" and "transport object" are consistent with the definitions in ALC [7] and LCT [8]. The terms "file" and "source object" are pseudonyms, but they are NOT pseudonyms for "object" like in FLUTE [10], since a file may be transmitted within an aggregated object, that is the only object that ALC needs to understand. Neumann, et al. Expires April 20, 2006 [Page 8] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 3. The Generalized Grouping Mechanism The generalized grouping mechanism allows each file of a FLUTE session to be labeled as being part of none, one or several logical groups. Logical aggregation is performed by using the generalized grouping mechanism. Since there is a strong incentive to only physically aggregate files that are logically related (Section 1.1.2), physical aggregation may use this generalized grouping mechanism too, in addition to the scheme introduced in Section 4. 3.1 Syntax of FDT Instance with the Generalized Grouping Mechanism The grouping mechanism is achieved by adding the element "Group" to the FDT. The element "Group" can be added to a "File" element, an "aggregatedFile" element (introduced in Section 4.3) or to the "FDT- Instance" element. In the first two cases it specifies that the file (or aggregated file) is part of a group that is identified by the value of the element entry "Group". A "Group" entry at "FDT- Instance" level specifies that all files (and aggregated files) listed in the FDT Instance are part of that group. The extended FDT Instance XML schema is specified in Section 4.3. 3.2 A simple example With this simple extension any type of relationship between files can be expressed. As an example we want to express the hierarchical relationship depicted in Figure 1. A web site is composed of two html pages (file1.html and file2.html). file1.html contains the image file3.jpg, and file2.html contains the image file4.jpg. Neumann, et al. Expires April 20, 2006 [Page 9] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 ----------------------------------------------- | WebSite | | -------------- -------------- | | | | | | | | | HtmlPage1 | | HtmlPage2 | | | | (file1.html, | | (file2.html, | | | | file3.jpg) | | file4.jpg) | | | | | | | | | -------------- -------------- | | | ----------------------------------------------- Example of a hierarchical relationship for a web site. Figure 1 The hierarchical relationship can be expressed as follow: All files are part of the group "WebSite"; file1.html and file3.jpg are part of the group "HtmlPage1"; file2.html and file4.jpg are part of the group "HtmlPage2". Other file relationships can easily be expressed with the generalized grouping mechanism. The relations between groups are only implicitly expressed (e.g. it it not explicitly stated in the above example that "HtmlPage1" is a sub-group of "WebSite"). Is there a need to specify the relationship between groups explicitly in some way in the FDT? Neumann, et al. Expires April 20, 2006 [Page 10] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 4. The Physical File Aggregation Scheme 4.1 multipart/mixed MIME type object and multipart/related MIME type object An aggregated object is either a multipart/mixed MIME type object as defined in MIME Part two [2] or a multipart/related MIME type object as defined in [4]. The aggregated object includes several files, each one delimited by the boundary delimiter defined in the MIME header. One body part (in MIME terminology) corresponds to one aggregated file. Multipart/related MIME type objects should be used in cases where a logical dependence of the files being aggregated needs to be expressed (Multipart/related was initially developed to send entire web-page, i.e. including all images and related files part of that web-page). In all other cases multipart/mixed MIME type object should be used. There are no restrictions nor recommendations regarding the MIME header fields of each body part compared to what is specified in MIME Part two [2]. Empty header fields are sufficient (i.e. the body parts are only delimited by the boundary delimiter without any header field), but the header field may be filled with any additionally required information. In some cases adding additional information for each body part may be useful. Especially if we want to enable a receiver that is not aware of the aggregated object FLUTE extension to process the aggregated object and reconstruct aggregated files, it is RECOMMENDED to include the "Content-Location" attribute in each body part MIME header field. 4.2 Extending the FDT with Aggregated Object Information The Aggregated Object Information (AOI) describes the aggregated object and its structure. In this section we describe a logical view of all information needed to process an aggregated object, and in Section 4.3 we describe its implementation within the FDT Instances as a "File" element for the aggregated object and a set of "aggregatedFile" elements. The AOI must enable a receiver to: o identify that an ALC object is an aggregated object, o identify and have a description of the files being transmitted in an aggregated object, Neumann, et al. Expires April 20, 2006 [Page 11] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 o know the position (i.e. offset) and length of each file within the aggregated object. Therefore the AOI MUST contain the following attributes: o The Aggregated Object's TOI value o The Aggregated Object's content type value, that MUST either be set to "multipart/mixed" or to "multipart/related" o The URI of each file being aggregated o The offset of each file within the aggregated object (not considering the boundary delimiter and the MIME header) o The transfer length of each file within the aggregated object, or the content length if the file is not content encoded o The number of files aggregated in one aggregated object. The attributes of the AOI MUST be included in the FLUTE FDT. The FDT Instances containing AOI are referred as "extended" FDT Instances in this document. Since the AOI is just an extension added to the FLUTE version 1 FDT, it is delivered within the FDT Instances, as specified in FLUTE [10]. The file aggregation scheme does not mandate any mechanism to carry the AOI, but it is RECOMMENDED that the AOI does not straddle several FDT Instances. A receiver can check if he knows the entire list of files of one aggregated object by checking if the number of described files is equal to the number of files specified in the AOI. It has to be discussed if carrying the AOI within one FDT Instance can be mandated as mandatory. The attribute number of files is no longer required in that case. 4.3 Syntax of FDT Instance with Aggregated Object Description Information The syntax of FDT Instances remains the same as the FLUTE version 1 specification, with the addition of the following enhancements: 1. An aggregated object has a "File" element entry in the FDT, like normal files. Neumann, et al. Expires April 20, 2006 [Page 12] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 * All rules of the FLUTE version 1 specification for "File" elements apply to this entry. * The entry MUST have the attribute "Content-Type" and its value must either be set to "multipart/mixed" or "multipart/related" according to the MIME object type used for the aggregated object. * The "Content-Location" attribute SHOULD contain a relative URI reference [5], since aggregated objects may have no absolute URI (they are not regular files). An example of such a relative URI for the aggregated object is "/AO1". * To differentiate an FDT file entry of a normal file of type "multipart/mixed" or "multipart/related" from an FDT file entry of an aggregated object, the receiver has to check if there exists elements of type "aggregatedFile" whose "AOTOI" attribute value is equal to the TOI of the aggregated object. * The entry MUST have the attribute "Number-of-Files" and its value is the number of aggregated files within the aggregated object. 2. The element "aggregatedFile" describing a file being aggregated is added to the XML Schema. For this element the attributes must be set according to the following rules: * The attribute "AOTOI", that identifies the TOI of the corresponding aggregated object, MUST be set. * The attribute "Content-Location" MUST be set and assigned a valid URI as defined in [10]. * The attributes "Content-Length" (or "Transfer-Length" if the file is content encoded FLUTE [10]) and "Content-Offset" MUST be specified. "Content-Offset" specifies the offset of the file within the aggregated object. More precisely, this is the number of bytes (8 bit words) from the start of the aggregated object up to the first byte of the file, not considering the boundary delimiter and the MIME header. (Note, that the use of multipart MIME ensures that the files are byte aligned). * The attributes "Content-Encoding" and "Content-MD5" MAY be used. In that case these attributes MUST be used for the purpose as described in [10]. The following specifies the XML Schema [11][12] for FDT Instance: Neumann, et al. Expires April 20, 2006 [Page 13] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 4.4 Symbol alignment of aggregated files In uses cases where the the aggregated files within the aggregated object needs to be symbol aligned, the mechanism described in this section SHOULD be used. The mechanism stays compatible with the MIME object format and allows symbol alignment in the same time. 4.4.1 MIME compatible padding We define a new MIME header field, that allows to add padding within the MIME part header. The field is defined as follows (it refers to several syntax rules that are defined by [1]): extension-field = "Padding" ":" *LWSP-char where *LWSP-char is filled with an appropriate number of whitespaces to achieve symbol alignment of the following file. Receivers that are not aware of this header field can process the MIME object anyhow, by just skipping process this field (this is the default behavior for unknown header fields). 4.5 Recovering files at FLUTE receiver supporting physical file aggregation 4.5.1 Recovering files before the entire reception of the aggregated object Aggregated objects SHOULD NOT be content encoded in order to enable file recovery from an aggregated object before the whole aggregated object is received/reconstructed. Content encoding largely restricts the ability to access the individual files within the aggregated object before content decoding was successful. Therefore we do not recommend content encoding of aggregated objects when partial Neumann, et al. Expires April 20, 2006 [Page 17] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 reliability is required. Conversely individual aggregated files may be content encoded. The information provided with the FDT Instances allows a receiver to identify all source blocks and source symbols for each aggregated file. File recovery is done, for each aggregated file, by: 1. Identifying the corresponding aggregated object using the "AOTOI" attribute, and thus the ALC object carrying the aggregated object. 2. Identifying the source symbols (and their corresponding source blocks) carrying the file data, using the relevant blocking algorithm and any related FEC-OTI parameters. The "Content- Offset" attribute is used to calculate the first transport object symbol and its corresponding source block of the file. The "Content-Length" (or "Transfer-Length") attribute is used to identify the remaining symbols (and their corresponding source blocks) of the file. Note that the start-of-file and end-of-file boundaries do not necessarily correspond to symbol boundaries, if the symbol alignment mechanism of Section 4.4 is not used. If the mechanism is used, we are ensured that the start-of-file corresponds to a symbol boundary. 3. Waiting until all symbols have been received or decoded to reconstruct the aggregated file. 4.5.2 Recovering files after the entire reception of the aggregated object After the entire reception of the aggregated objects the receiver is assured that he received all symbols and source blocks to reconstruct all aggregated files. As in the previous section the information provided with the FDT Instances allows a receiver to identify for each aggregated file the symbols carrying the file data, and therefore reconstruct the individual files. 4.6 Recovering files at FLUTE receiver that does not support physical file aggregation A receiver that does not support physical file aggregation can recover aggregated files after full reception of the aggregated object, if enough information is carried within the aggregated object (see Section 4.1). In that case a MIME reader can interpret the file, and extract the aggregated file out of it. Neumann, et al. Expires April 20, 2006 [Page 18] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 4.7 Limitations The following limitations have to be considered when using object aggregation: 1. No individual file can be modified within an aggregated object. If an update is required at least two possibilities exist. Other mechanisms may be used, but are out of scope of this specification: (1) a brand new aggregated object is created and replaces the previous aggregated object whose transmission MUST stop; or (2) the new file is sent individually by FLUTE along with an FDT entry that shows that it out dates the previous version. If a File URI appears on a "higher" TOI than an aggregated object carrying it, the receiver SHALL assume that the individual file is the newer version. Also, an aggregated object on a higher TOI which contains a file previously described on a lower TOI SHALL be assumed to contain a newer (or equal) version. To that purpose, the TOI assigned by the sender to each object MUST start with at least 1 and be incremented by one for each new object. This ensures that the receiver can unambiguously determine which instance of a certain file URI is not (obsolete (the one with the logically highest TOI). This has no implication on sending or receiving order, only on allocation. 2. The physical file aggregation scheme offers a limited per-file filtering. The limitation is that a large part of the aggregated object may have to be received and processed before a FLUTE receiver can extract an individual file from it, when only a small subset of the aggregated files are of interest to a FLUTE receiver. It is therefore the responsibility of the FLUTE sender to create an homogeneous aggregation. The criteria to decide what files can be aggregated or not are out of scope of this document. Neumann, et al. Expires April 20, 2006 [Page 19] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 5. FLUTE version 1 backward compatibility The XML Schema described in Section 4.2 is not backward compatible with the XML Schema described in the FLUTE version 1 specification. FLUTE version 1 does not allow the addition of new types of elements in the XML Schema. An extra redirection to "extended" FDT Instances is introduced to be backward compatible with FLUTE version 1 specifications. This enables the combined use of FLUTE version 1 FDT Instance specifications in combination with the extended FDT schema of this specification. Yet if all receivers support this document's extended FDT schema, then the redirection mechanism is not required. 5.1 Redirection mechanism The backward compatibility mechanism consists carrying the extended FDT Instances on a non-'0' TOIs. The TOI of the extended FDT Instances is signaled to the receivers with a new attribute, "FDTInstanceRedirection". The value of that attribute MUST remain the same during an entire file delivery session. o A receiver that only accepts FDT Instances conforming to the FLUTE version 1 specifications and that is not aware of the physical file aggregation scheme skips processing of the "FDTInstanceRedirection" attribute and therefore does not process the extended FDT Instances carried on the non-'0' TOI. o A receiver that is aware of the "file aggregation extension" processes the FDT redirection attribute, and therefore receives and processes the extended FDT Instances. The extended FDT Instances, carried on a non-'0' TOI, have, as the non-extended FDT Instances, an FDT Instance ID. The FDT Instance ID is signaled to the receivers with an FDT Instance header as specified in FLUTE version 1. FDT Instances on TOI '0' and on non-'0' TOI share the same FDT Instance IDs space. That means that an FDT Instance ID used on one TOI MUST NOT be used anymore for any other FDT Instance on any TOI. The FDT Instance ID MUST be incremented by one instead (wraparound considerations are the same as for FLUTE version 1). With this mechanism the most up-to-date (extended or non-extended) FDT Instance has always the greatest FDT Instance ID value. A consequence is that the FDT Instance ID values for one TOI are not necessarily contiguous. Neumann, et al. Expires April 20, 2006 [Page 20] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 6. Security Considerations The security considerations that apply to FLUTE version 1, also apply to this document. A malicious attacker may send forged FDT Instances. He could use the redirection mechanism (redirecting to false TOIs) or directly send forged FDT Instances, with false descriptions of aggregated objects. The attacker may use this mechanism to send malicious active content like a Trojan horse or some other type of virus within one aggregated object (as a whole) or within the aggregated files. It is thus STRONGLY RECOMMENDED that the FLUTE delivery service at the receiver does not have write access to the system files or directories, or any other critical areas, and that authentication schemes be used. Neumann, et al. Expires April 20, 2006 [Page 21] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 7. IANA Considerations No information in this specification is directly subject to IANA registration. However, building blocks components used by ALC may introduce additional IANA considerations. Neumann, et al. Expires April 20, 2006 [Page 22] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 8. Acknowledgments The authors gratefully acknowledge the contributions of Nabil Layaida. Thanks also for the helpful comments of Michael Luby and Thorsten Lohmar. Neumann, et al. Expires April 20, 2006 [Page 23] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 9. References 9.1 Normative References [1] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998. [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [7] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002. [8] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002. [9] Luby, M. and L. Vicisano, "Compact Forward Error Correction (FEC) Schemes", RFC 3695, February 2004. [10] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, "FLUTE - File Delivery over Unidirectional Transport", RFC 3926, October 2004. [11] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C Recommendation, May 2001. [12] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C Recommendation, May 2001. Neumann, et al. Expires April 20, 2006 [Page 24] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 9.2 Informative References [13] Roca, V. and C. Neumann, "Design, Evaluation and Comparistion of Four Large Block FEC Codecs, LDPC, LDGM, LDGM Staircase and LDGM Triangle, plus a Reed-Solomon Small Block FEC Codec", INRIA Research Report Number 5225, June 2004. [14] Byers, J., Luby, M., Mitzenmacher, M., and A. Rege, "A digital fountain approach to reliable distribution of bulk data", ACM SIGCOMM 98, August 1998. Authors' Addresses Christoph Neumann INRIA Rhone-Alpes 655, av. de l'Europe, Montbonnot St Ismier cedex, 38334 France Phone: +33 4 76 61 52 69 Email: christoph.neumann_(at)_inrialpes.fr Vincent Roca INRIA Rhone-Alpes 655, av. de l'Europe, Montbonnot St Ismier cedex, 38334 France Phone: +33 4 76 61 52 16 Email: vincent.roca_(at)_inrialpes.fr Rod Walsh Nokia Visiokatu 1 Tampere, 33720 Finland Email: rod.walsh_(at)_nokia.com Neumann, et al. Expires April 20, 2006 [Page 25] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 Appendix A. Example of FDT Instance (informative) MP3_tracks MP3_tracks A simple FDT Instance using the generalized grouping mechanism. The files on TOI='1' and TOI='2' are part of the group "MP3_Tracks". Neumann, et al. Expires April 20, 2006 [Page 26] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 Appendix B. Example of FDT Instance (informative) A simple FDT Instance using the physical file aggregation scheme. The files "http://www.example.com/menu/description.html" and "http://www.example.com/menu/details.html" are carried within the aggregated object, which has an TOI='1'. Neumann, et al. Expires April 20, 2006 [Page 27] Internet-Draft A File Aggregation Scheme for FLUTE October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Neumann, et al. Expires April 20, 2006 [Page 28]