RMT H. Mehta Internet-Draft R. Walsh Expires: August 5, 2007 Nokia V. Roca INRIA Rhone-Alpes J. Peltotalo S. Peltotalo Tampere University of Technology February 1, 2007 FLUTE Interoperability Testing Guidelines draft-mehta-rmt-flute-iop-07 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 August 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Mehta, et al. Expires August 5, 2007 [Page 1] Internet-Draft FLUTE IOP February 2007 Abstract This document describes a possible testing strategy for interoperability among implementations of the File Delivery over Unidirectional Transport (FLUTE) protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Test Environment Setup . . . . . . . . . . . . . . . . . . . . 5 3.1. ALC/LCT Conformance and Minimum Feature Set . . . . . . . 5 3.2. Basic FLUTE Testing Architecture . . . . . . . . . . . . . 6 3.3. Preconditions for Testing . . . . . . . . . . . . . . . . 7 4. Basic FLUTE Tests . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Simple FLUTE Connectivity . . . . . . . . . . . . . . . . 8 4.2. Small File (Single Block) Test . . . . . . . . . . . . . . 8 4.3. Large File (Multiple Block) Test . . . . . . . . . . . . . 9 5. FLUTE Transport Tests . . . . . . . . . . . . . . . . . . . . 11 6. Multiple Files within a Session . . . . . . . . . . . . . . . 14 7. Testing Interoperability for Modified FDTs . . . . . . . . . . 16 8. Recommended Advanced FLUTE Tests . . . . . . . . . . . . . . . 17 8.1. Interoperability across Simultaneous Multiple Sessions . . 17 8.2. Interoperability for Identical Files across Multiple Sessions or Channels . . . . . . . . . . . . . . . . . . . 17 9. FDT Instance Interoperability Tests . . . . . . . . . . . . . 18 10. Interoperability Test Suite . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 14.1. Normative References . . . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27 Mehta, et al. Expires August 5, 2007 [Page 2] Internet-Draft FLUTE IOP February 2007 1. Introduction This document describes a testing strategy for File Delivery over Unidirectional Transport (FLUTE) [1] implementations. The tests are intended to help demonstrate interoperability of multiple implementations, and to illustrate common implementation errors. They are not intended to be an exhaustive set of tests and passing these tests does not necessarily imply conformance to the complete FLUTE specification. The purpose of this document is to demonstrate protocol maturity through successful interoperability and hence support the IETF standards track advancement of FLUTE. Mehta, et al. Expires August 5, 2007 [Page 3] Internet-Draft FLUTE IOP February 2007 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. ALC/LCT session: Logically grouped ALC/LCT channels associated with a single sender sending packets with ALC/LCT headers for one or more channels. FLUTE session: The flow of data between a sender and receivers within a defined context and time over an ALC/LCT session using FLUTE headers. ALC/LCT implementation: The implementation of the ALC/LCT protocols used by the FLUTE implementation. FLUTE implementation: The tool implementing the FLUTE and ALC/LCT specifications. Mehta, et al. Expires August 5, 2007 [Page 4] Internet-Draft FLUTE IOP February 2007 3. Test Environment Setup Neither ALC/LCT [3] [4] nor FLUTE restrict implementations to a single transport mechanism. Therefore FLUTE sessions (and ALC/LCT sessions) can operate on many different transport mechanisms, like unicast connections, multicast connections, bi-directional, uni- directional connections, using either IPv4 or IPv6. All of these possibilities are valid from an ALC/LCT and FLUTE perspective. Therefore a FLUTE deployment must first determine which transport mechanisms are to be supported. Many external tools can be used during interoperability testing. Some of these are: o diff [6]: This tool is used to identify the differences between two file instances when both file instances are available locally. o md5sum [7]: This tool is used to check that two file instances are identical. It is useful when the two file instances are not available locally. It is also recommended that the optional field in the FDT be used for the md5 digest of transmitted files. o ping [8]: This tool is used to check the unicast connectivity of the two testing hosts. It is recommended that the users of the FLUTE implementations begin the testing process by running the ping mechanism to test the connection to the other FLUTE implementation. 3.1. ALC/LCT Conformance and Minimum Feature Set FLUTE is based on ALC/LCT, therefore FLUTE interoperability testing requires that ALC/LCT conformance be tested. However, since this is outside the scope of this document, and since ALC/LCT leaves open several possibilities, we first define a minimum required ALC/LCT feature set. It is highly recommended that a FLUTE application supports the following minimum ALC/LCT feature set in order to simplify FLUTE conformance tests. This feature set presents some of the available options and the minimum required features for meaningful interoperability testing. However, a FLUTE application may make other choices while being fully compliant to the FLUTE specification. Mehta, et al. Expires August 5, 2007 [Page 5] Internet-Draft FLUTE IOP February 2007 Feature/Feature set Options Minimum CCI field 32*(C+1) bits 32 bits TSI field 32*S+16*H bits 32 bits TOI field 32*O+16*H bits 32 bits SCT field present if T==1 none ERT field present if R==1 none Congestion control protocol none, WEBRC, none RLC, FLID-SL FEC Code Compact No-Code, Compact open codes, No-Code proprietary codes FEC Encoding ID 0, 128, 129, 130 0 (Compact No-Code) Using a Compact No-Code FEC [5] avoids testing for the FEC code of the ALC/LCT implementations. Since this is outside the scope of the present document, it is recommended that Compact No-Code FEC be used, prior to any optional FEC codes. The FEC encoding ID for this case is 0. Using no congestion control protocol avoids testing for congestion control protocol implementations. Since this is outside the scope of this document, it is recommended that no congestion control be used, prior to any optional congestion control blocks. This requires that testers minimize congestion on the Internet manually. This minimum feature set is only intended to simplify FLUTE interoperability testing. However, ALC/LCT compliance tests may not restrict themselves to this minimum feature set. 3.2. Basic FLUTE Testing Architecture An architecture for testing the basic functioning of FLUTE implementations is shown in Figure 1. +-----------------+ +-----------------+ | First FLUTE | | Second FLUTE | | Test setup | | Test setup | | +-------------+ | | +-------------+ | | | Sender | |--------->| | Receiver | | | +-------------+ | | +-------------+ | | +-------------+ | | +-------------+ | | | Receiver | |<---------| | Sender | | | +-------------+ | | +-------------+ | +-----------------+ +-----------------+ Mehta, et al. Expires August 5, 2007 [Page 6] Internet-Draft FLUTE IOP February 2007 Figure 1: Basic FLUTE testing architecture The test architecture comprises of two connected FLUTE senders and receivers. The sender and receiver MAY be on the same physical machine or on different physical machines. It is also possible to have just a receiver implementation at one end to check receiver interoperability only. 3.3. Preconditions for Testing The following tests assume that the channel(s) for transmission of FLUTE data and files have been appropriately configured and that connectivity has been established between the sending and receiving implementations. It is recommended testing procedure that the sender uses a value of 0 for the Transport Object Identifier (TOI) for the File Delivery Table (FDT) Instance. The use of non-zero values for the TOI in FDT Instances is out of the scope of this document. Further, the tests assume that a mechanism for snooping packets at the receiver is available. However, such a mechanism is beyond the scope of this document and will not be discussed here. End-to-end connectivity must allow FLUTE packets to pass for the selected transport mechanisms (e.g. multicast, IPv6). It should be noted that the ping test only indicates unicast ICMP connectivity end-to-end, including firewalls en route. Mehta, et al. Expires August 5, 2007 [Page 7] Internet-Draft FLUTE IOP February 2007 4. Basic FLUTE Tests These tests are meant to assess the basic conformance of the FLUTE application in simple operating situations. In these cases, a single file is sent and received using the FLUTE transport mechanism. In all the following elementary tests, the test architecture outlined in Section 3.2 SHOULD be used. The tests MUST be carried out on both the sending and receiving implementations of each FLUTE application. 4.1. Simple FLUTE Connectivity This test is meant to verify the successful reception and interpretation of the FDT. A single file is transmitted from the sending implementation to the receiving implementation using FLUTE. The FDT Instance MUST be sufficiently small so that it is contained within a single encoding symbol in a single ALC packet. The file MUST be sufficiently small so that it is contained within a single ALC packet. The ALC packets MUST be sufficiently small to not exceed a single MTU (Maximum Transfer Unit). This implies that the file is contained within a single source block and a single encoding symbol. The sending implementation sends the file using FLUTE to the receiver. Upon receiving the file, the receiving implementation checks that: o The FDT has been properly received. o The receiver is able to interpret the FDT. o The file is correctly received and that there is no difference between the file sent and the file received. The file MAY be compared with the original copy of the file at the sender by using utilities such as 'diff' and 'md5sum'. 4.2. Small File (Single Block) Test This test is meant to verify the reception of multi-packet and multi- symbol files. The basic usage of the blocking algorithm is thus tested at the sending and receiving implementations. A single file is transmitted from the sending implementation to the receiving implementation using FLUTE. The file MUST be sufficiently small so that it is contained within a single source block. Note that when using a Compact No-Code FEC, there is no actual limitation Mehta, et al. Expires August 5, 2007 [Page 8] Internet-Draft FLUTE IOP February 2007 for the source block length, but the implementation of the FEC code must have set the value for the Maximum Source Block Length (absolute maximum is 4294967295 source symbols). For example if the Encoding Symbol Length is 1400 bytes and the Maximum Source Block Length is 10, then the upper limit for the file size is 14000 bytes. However, the file MUST span over multiple encoding symbols and hence multiple packets. A minimum of 10 symbols is RECOMMENDED. The sending implementation sends the file using FLUTE to the receiver. Upon receiving the file, the receiving implementation checks that: o The FDT is successfully received and interpreted. o The file is successfully received. o The file is successfully reconstructed from the corresponding received packets and that there is no difference between the file sent and the file received. The file MAY be compared with the original copy of the file at the sender by using utilities such as 'diff' and 'md5sum'. 4.3. Large File (Multiple Block) Test This test is meant to test the reception of large, multi-block files. A single large file is transmitted from the sending implementation to the receiving implementation using FLUTE. The file SHOULD be large enough so that it is contained in multiple source blocks. Note that when using a Compact No-Code FEC, there is no actual limitation for the source block length, but the implementation of the code must have set the value for the Maximum Source Block Length (absolute maximum is 4294967295 source symbols). For example if the Encoding Symbol Length is 1400 bytes and the Maximum Source Block Length is 10, then the lower limit for the file size is 14001 bytes. This test SHOULD be repeated with several file sizes in order to test the source blocking functionality in several situations. The sending implementation sends the file using FLUTE to the receiver. Upon receiving the file, the receiving implementation checks that: o The FDT is successfully received and interpreted. o The file is successfully received. Mehta, et al. Expires August 5, 2007 [Page 9] Internet-Draft FLUTE IOP February 2007 o The file is successfully reconstructed from the corresponding received packets and that there is no difference between the file sent and the file received. The file MAY be compared with the original copy of the file at the sender by using utilities such as 'diff' and 'md5sum'. Mehta, et al. Expires August 5, 2007 [Page 10] Internet-Draft FLUTE IOP February 2007 5. FLUTE Transport Tests The aim of these tests is to verify that files/objects can be exchanged between the two FLUTE implementations using a FLUTE session and that the FLUTE and ALC/LCT headers are correctly transmitted. The following forms a minimum set of conditions that must be verified for FLUTE interoperability. The test architecture outlined in Section 3.2 SHOULD be used. The initial test is for the first FLUTE implementation to transmit and the second to receive. The process is then reversed, with the second implementation sending and the first receiving. The sending implementation transmits a single file with a complete File Delivery Table. The File Delivery Table contains the attributes of the file that are required by the receiver. At minimum, the complete FDT consists of a TOI attribute and Content-Location attribute. The FDT MAY also contain the FEC encoding scheme that has been used by the sender. It is recommended to deliver the complete FDT in a single FDT Instance. These tests SHOULD be carried out for various file sizes. The following cases of operation MUST be verified: The transmitting implementation is required to verify the following: o The receiver joins the session prior to the beginning of transmission of the first packet in the session. For this case, the FDT MUST be delivered before the transmission of the file begins. o The case when the sender retransmits the file (like a carousel). It is recommended that the sender transmit the objects at least 3 times. The receiver joins the session any time after the first packet in the session has been transmitted. For this case, the FDT MUST be delivered before the transmission of the file begins. o The case when packets containing FDT Instances are multiplexed with packets containing parts of the file in transmission. This case MUST be tested for receivers, i.e. it MUST be ensured that a receiver can handle this case correctly. These tests MUST be carried out both with and without the use of A-flags and B-flags in the ALC/LCT header. The A-flag may be used in an empty packet as defined by ALC or by inclusion within the last packet of the transmission. In both cases, it is recommended that Mehta, et al. Expires August 5, 2007 [Page 11] Internet-Draft FLUTE IOP February 2007 the packet containing the A-flag be transmitted three times. The sending implementation is required to verify the following: o At least one complete FDT MUST be transmitted during the session by the sending implementation. o A Transport Session Identifier (TSI) MUST be transmitted so as to uniquely identify the session along with the IP address of the sender. o The value of the TOI MUST be 0 for all the packets containing FDT Instances for the test. Although this is not a limitation set down by FLUTE, it is the recommended testing procedure. The receiving implementation is required to verify the following: o A TSI MUST be present and MUST be the same as transmitted by the sender for the session: The (source IP address, TSI) pair identifies the session. This pair MUST be tested for all packets received to avoid session corruption between several simultaneous sessions. o The TOI MUST be present in each packet received other than packets signalling the end of a session using the A-flag: The Transport Object Identifier identifies the object within the session that the packet is a part of. o The TOI MUST have a value of 0 for the FDT Instance: The receiver identifies a packet containing a part (or all) of the FDT Instance by the value of the TOI for the packet being 0. It is recommended that each packet containing a part of the FDT Instance be checked for the TOI value. o End of session or file: The receiver MUST be able to recognize the end of a session by the presence of the A-flag and the end of transmission of a particular file by the presence of the B-flag. The A-flag may be received in an empty packet or in the last packet of the transmission, which MAY be transmitted multiple times. The receiver MUST be able to handle both cases. o At least one complete FDT MUST be received during the session. o Every FDT Instance received MUST conform to the XML schema defined in [1]. Mehta, et al. Expires August 5, 2007 [Page 12] Internet-Draft FLUTE IOP February 2007 o The file SHOULD be verified for its attributes, that is, the information received as part of the FDT should be compared with the actual file itself to verify correctness of interpretation. The file MAY also be compared with the original copy of the file at the sender by using utilities such as 'diff' and 'md5sum'. Mehta, et al. Expires August 5, 2007 [Page 13] Internet-Draft FLUTE IOP February 2007 6. Multiple Files within a Session The aim of this test is to verify the interoperability of FLUTE implementations wherein multiple files are transmitted by the sender implementation during a session. The system architecture used is the same as used for the tests described in Section 3.2. In this test, the sender transmits more than one file during a session. The files are transmitted as separate objects. The sender MUST transmit a complete File Delivery Table during the entire session. The complete FDT MUST contain attributes of all the files transmitted during the session. The complete FDT MAY be compiled from a number of FDT Instances. At the sender, the following cases of operation SHOULD be verified: o The sender MUST verify the conditions for interoperability described in Section 5. o The sender transmits the complete FDT in a single FDT Instance. However the FDT Instance may be split into several ALC packets. The transmission of the FDT is not multiplexed with the transmission of the files. o The sender transmits the complete FDT in multiple FDT Instances, so that the complete set of attributes describing a particular file are transmitted before the transmission of the file itself. o Further, FDT Instances and files are sent alternately. The complete set of attributes for a file may be contained within a single FDT Instance, or may be contained in multiple FDT Instances. Again the FDT Instances may be split into several ALC packets. At the receiver, the conditions described in Section 5 MUST be verified. Apart from this, the following SHOULD be verified at the receiving implementation: o The receiver MUST be able to map the attributes for the files described in the FDT to the respective file. At the minimum, this involves mapping the TOI and Content-Location attributes to the respective file. o The file SHOULD be verified for its attributes, that is, the information received as part of the FDT should be compared with the actual file itself to verify correctness of interpretation. Mehta, et al. Expires August 5, 2007 [Page 14] Internet-Draft FLUTE IOP February 2007 The file MAY also be compared with the original copy of the file at the sender by using utilities such as 'diff' and 'md5sum'. All the above conditions SHOULD be verified for the following cases: o The receiver joins the session prior to the beginning of transmission of the first packet in the session. o The receiver joins the session after the first packet in the session has been transmitted. o The receiver joins the session prior to the beginning of transmission of the first packet in the session, with the sending implementation retransmitting files (like a carousel). It is recommended that the sender transmit the files at least 3 times. o The receiver joins the session after the first packet in the session has been transmitted, with the sending implementation retransmitting files. It is recommended that the sender transmit the files at least 3 times. Further, the case when packets containing FDT Instances are multiplexed with other objects being transmitted MAY also be verified for sender implementations and MUST be verified for receiving implementations. Note: For verification of receiving multiplexed packets, multiplexing at the sender, or another method, such as enforced packet reordering in the network may be used. It is important to note that the sender may not be required to transmit multiple files within a session. However, it is important that all receivers possess the capability to receive one and more files during a session. Mehta, et al. Expires August 5, 2007 [Page 15] Internet-Draft FLUTE IOP February 2007 7. Testing Interoperability for Modified FDTs This section outlines some tests that can be used to verify the interoperability operation of FLUTE implementations in the scenario where the FDT is modified during a session. The modification of the FDT may include several scenarios. Some of the possible scenarios are: o When a file is added to the transmission that was not previously described in any FDT Instance. o When a file that was previously to be transmitted is removed from transmission. This can be detected from the use of, for example, the A-flag, the B-flag and the FDT Instance Expiry attribute. o When additional parameters previously not in the FDT are added to the FDT to describe a file being transmitted within the session. Note: the sender MUST NOT change the parameters already described for a specific TOI, but it can complement the description for example by adding MD5 checksum. o The contents of a file are modified. This is when a previously described file identifier is used with a new TOI, implicitly expiring the data associated with the old TOI. This is not an exhaustive list and there may be several other scenarios that warrant changes to the FDT. To verify interoperability under these tests, the sender and the receiver MUST satisfy the tests described in Section 5. Further, the following SHOULD be verified at the receiver: o That the receiver is able to map the TOIs and Content-Locations obtained from the FDT for each file correctly. o When any part of a new version of a previously described file (on a new TOI) is received in the same session as parts or all of the previous version of the file (same identifier, i.e. Content- Location), the new file MUST be received completely and without corruption. Mehta, et al. Expires August 5, 2007 [Page 16] Internet-Draft FLUTE IOP February 2007 8. Recommended Advanced FLUTE Tests This section details tests to determine interoperability under advanced or potentially difficult operating conditions. 8.1. Interoperability across Simultaneous Multiple Sessions The sender MAY not be required to operate simultaneous multiple sessions of FLUTE, however, it is important that the receiver implementation MUST be able to handle simultaneous multiple sessions of FLUTE. This section outlines some tests that are recommended to be verified to establish interoperability during multiple simultaneous sessions at the receiver. The test architecture is the same as that described in Section 3.2. Interoperability with multiple simultaneous sessions MUST be tested at the receiver using one channel without a congestion control protocol. Further it is recommended to test this also with multiple (at least two) channels and a multiple-rate congestion control protocol. To begin receiving the transmission on multiple sessions, the receiver MUST know the senders' IP addresses, the number of channels in each session, the congestion control protocol used, the destination IP address and port number of each of the channels in the sessions, and the TSI of each of the sessions. The receiver SHOULD be able to de-multiplex packets and buffer them, if required, suitably based on the information from the FDT Instances, the EXT_FTI information and possibly out of band information within each session as well as across multiple sessions. Demultiplexing packets with the same TSI but different source IP addresses as being from different sessions should not cause an error. 8.2. Interoperability for Identical Files across Multiple Sessions or Channels The receiver SHOULD be able to deal with identical files received over different sessions as well as over different channels within a session. The receiver SHOULD be able to identify the files as coming over different sessions and demultiplex and possibly buffer them suitably. Methods of dealing with identical files once they have been received are left to implementations. Mehta, et al. Expires August 5, 2007 [Page 17] Internet-Draft FLUTE IOP February 2007 9. FDT Instance Interoperability Tests This section details tests that need to be verified to ensure that the transmission of the FDT Instance packets and the syntax of the FDT Instances is correct. The test architecture is the same as that outlined in Section 3.2. As FDT Instances contain critical information with regard to file delivery, it is recommended that the following tests be conducted on every FDT Instance packet within a session: o Checking the validity of the FDT Instance Header (EXT_FDT LCT extension header): The HET (Header Extension Type) of the EXT_FDT is 192. o The FDT Instance Header MUST be identical for all ALC packets carrying parts of a particular FDT Instance. o All packets carrying a part or all of the FDT Instance MUST have the FDT Instance Header. o FDT Instance ID wrap-around MUST be tested. The FDT Instance ID wraps around to 0 after (2^24-1). Previously received unexpired FDT data at the receiver SHOULD not be lost. o The FDT Instance MUST conform to the XML schema defined in [1]. o The FDT Instance root element 'FDT-Instance' MUST contain an 'Expires' attribute with a valid Network Time Protocol (NTP) time value. o Each 'File' element declared under the 'FDT-Instance' element MUST contain at least the attributes 'TOI' and 'Content-Location'. Mehta, et al. Expires August 5, 2007 [Page 18] Internet-Draft FLUTE IOP February 2007 10. Interoperability Test Suite This section describes a test suite that can be used for interoperability testing among FLUTE implementations. The test suite consists of example FDT Instances that may be used for conducting some of the interoperability tests described in earlier sections of this document. The following is an example of an FDT Instance containing information about the transmission of a single, small file (with a length of 170 bytes as indicated in the Content-Length attribute). An FDT Instance along these lines can be used to conduct the test described in Section 4.1. The following is an example of an FDT Instance that describes the attributes for a 'large' file that can be used to conduct the interoperability tests described in Sections 4.2 and 5. The following is an example of an FDT Instance that contains transmission attributes for multiple files. This corresponds to the tests described in Section 6. Mehta, et al. Expires August 5, 2007 [Page 19] Internet-Draft FLUTE IOP February 2007 The following is an example of FDT Instances that can be used to test interoperability in the presence of multiple FDT Instances within the same complete FDT. This can be used to conduct tests described in Sections 6 and 9. Mehta, et al. Expires August 5, 2007 [Page 20] Internet-Draft FLUTE IOP February 2007 Mehta, et al. Expires August 5, 2007 [Page 21] Internet-Draft FLUTE IOP February 2007 11. Security Considerations FLUTE implementations are subject to security considerations mentioned in [1]. There are no additional security considerations resulting from the testing guidelines mentioned in this document. Mehta, et al. Expires August 5, 2007 [Page 22] Internet-Draft FLUTE IOP February 2007 12. IANA Considerations No information in this specification is directly subject to IANA registration. Mehta, et al. Expires August 5, 2007 [Page 23] Internet-Draft FLUTE IOP February 2007 13. Acknowledgements The authors would like to thank Pasi Matilainen and Juha-Pekka Luoma for their contributions and feedback on this document. Mehta, et al. Expires August 5, 2007 [Page 24] Internet-Draft FLUTE IOP February 2007 14. References 14.1. Normative References [1] Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca, "FLUTE - File Delivery over Unidirectional Transport", draft-ietf-rmt-flute-revised-03 (work in progress), January 2007. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [3] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", draft-ietf-rmt-pi-alc-revised-03 (work in progress), April 2006. [4] Luby, M., Watson, M., and L. Vicisano, "Layered Coding Transport (LCT) Building Block", draft-ietf-rmt-bb-lct-revised-04 (work in progress), June 2006. [5] Watson, M., "Basic Forward Error Correction (FEC) Schemes", draft-ietf-rmt-bb-fec-basic-schemes-revised-02 (work in progress), March 2006. 14.2. Informative References [6] The GNU Project, "Diffutils", http://www.gnu.org/software/diffutils/diffutils.html, June 2006. [7] The GNU Project, "Textutils", http://www.gnu.org/software/textutils/textutils.html, June 2006. [8] The Debian Project, "Ping", http://packages.debian.org/stable/net/iputils-ping, June 2006. Mehta, et al. Expires August 5, 2007 [Page 25] Internet-Draft FLUTE IOP February 2007 Authors' Addresses Harsh Mehta Nokia P.O. Box 100 (Visiokatu 1) Tampere FIN-33721 Finland Email: harsh.mehta (at) nokia.com Rod Walsh Nokia P.O. Box 100 (Visiokatu 1) Tampere FIN-33721 Finland Email: rod.walsh (at) nokia.com Vincent Roca INRIA Rhone-Alpes 655, av. de l'Europe; Montonnot St Ismier cedex 38334 France Email: vincent.roca (at) inrialpes.fr Jani Peltotalo Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FIN-33101 Finland Email: jani.peltotalo (at) tut.fi Sami Peltotalo Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FIN-33101 Finland Email: sami.peltotalo (at) tut.fi Mehta, et al. Expires August 5, 2007 [Page 26] Internet-Draft FLUTE IOP February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Mehta, et al. Expires August 5, 2007 [Page 27]