RMT H. Mehta Internet-Draft Nokia Expires: May 13, 2004 November 13, 2003 FLUTE Interoperabtility Testing Guidelines draft-mehta-rmt-flute-iop-00.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 13, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo describes a possible testing strategy for interoperability among implementations of the File Delivery over Unidirection Transport (FLUTE) protocol. Mehta Expires May 13, 2004 [Page 1] Internet-Draft FLUTE Interoperabtility Testing Guidelines November 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Basic FLUTE operation . . . . . . . . . . . . . . . . . . . . 5 3.1 The Ping test . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Preconditions for testing . . . . . . . . . . . . . . . . . . 5 3.3 Basic transport . . . . . . . . . . . . . . . . . . . . . . . 5 3.4 Multiple Files within a session . . . . . . . . . . . . . . . 7 3.5 Testing interoperability for modified FDTs . . . . . . . . . . 9 4. Recommended Advanced FLUTE tests . . . . . . . . . . . . . . . 10 4.1 Interoperability across simultaneous multiple sessions . . . . 10 4.2 Interoperability for identical files across multiple session or channels . . . . . . . . . . . . . . . . . . . . . 10 5. FDT Instance and Payload Interoperability Tests . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15 Mehta Expires May 13, 2004 [Page 2] Internet-Draft FLUTE Interoperabtility Testing Guidelines November 2003 1. Introduction This memo describes a possible testing strategy for 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. Mehta Expires May 13, 2004 [Page 3] Internet-Draft FLUTE Interoperabtility Testing Guidelines November 2003 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]. Mehta Expires May 13, 2004 [Page 4] Internet-Draft FLUTE Interoperabtility Testing Guidelines November 2003 3. Basic FLUTE operation The architecture for testing the basic functioning of the FLUTE implementations is shown in Figure 1. +-----------------+ +-----------------+ | First FLUTE | | Second FLUTE | | Test setup | | Test setup | | +-------------+ | | +-------------+ | | | Sender | |--------->| | Receiver | | | +-------------+ | | +-------------+ | | +-------------+ | | +-------------+ | | | Receiver | |<---------| | Sender | | | +-------------+ | | +-------------+ | +-----------------+ +-----------------+ 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. The receiver may be a unidirectional receiver. It is also possible to have just a receiver implementation at one end to check receiver interoperability only. The implementations may be connected over a unicast LAN segment, over multicast tunneled through a unicast connection or over a multicast connection. These tests assume the use of FEC coding scheme with FEC Encoding ID 0 also known as the compact no code FEC scheme [5]. 3.1 The Ping test 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.2 Preconditions for testing The following tests assume that the channel for transmission of FLUTE data and files has been appropriately configured and that connectivity has been established between the sending and receiving implementations. It is also assumed that for these tests, the sender uses a value of 0 for the Transmission Object Identifier (TOI) for the File Delivery Table (FDT). 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. 3.3 Basic transport Mehta Expires May 13, 2004 [Page 5] Internet-Draft FLUTE Interoperabtility Testing Guidelines November 2003 The aim of this test is to verify that FLUTE data can be exchanged between the two FLUTE implementations using an ALC session and that the FLUTE and ALC data is correctly transmitted. 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. Each sending implementation transmits a single complete file with a complete File Description Table. For the first test, the FDT MUST be delivered before the transmission of the file begins. Later sections in this document describe other tests that verify operation in scenarios where the FDT is multiplexed with the file. The following tests form a minimum set of conditions for interoperability. These tests MUST be carried out both with and without the use of A-flags and B-flags in the ALC/LCT header [3][4]. The transmitting implementation is required to verify the following: o At least one complete FDT MUST be transmitted during the session by the sender implementation. o A valid 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. Although this is not a limitation set down by FLUTE, it is a testing requirement. o Signaling end of session: the sender signals the end of the transmission by using the A-flag in the ALC 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 the packet be transmitted multiple times. 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 (IP address, TSI) pair identifies the session. Since it may not be feasible to check all the packets for the presence of the TSI, it is recommended that at least every tenth packet be checked. o The TOI MUST be present in each packet received other than packets signaling the end of a session using the A-flag: The Transmission Object Identifier identifies the object within the session that the packet is a part of. Mehta Expires May 13, 2004 [Page 6] Internet-Draft FLUTE Interoperabtility Testing Guidelines November 2003 o The TOI MUST have a value of 0 for the FDT: The receiver identifies a packet containing a part (or all) of the FDT by the value of the TOI for the packet being 0. It is recommended that each packet containing a part of the FDT be checked for the TOI value. o Every FDT Instance packet MUST contain a valid TOI: Each packet with a part of an FDT Instance MUST have a valid TOI in its header. 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 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: The File Description Table contains the attributes of the file that are required by the receiver. At minimum, the complete FDT consists of a valid TOI. The FDT MAY also contain the FEC encoding scheme that has been used by the sender. o The FDT received MUST conform to the schema defined in [1]. All the above conditions MUST also 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 case when the sender uses a carousel to transmit. It is recommended that the sender transmit the files 3 to 10 times. The receiver joins the session any time after the first packet in the session has been transmitted. 3.4 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 earlier in this section. In this test, the sender transmits more that one file during a session. The files are transmitted as separate objects. However, the sender transmits a single complete File Description Table during the entire session. This means that the attributes of all the files are Mehta Expires May 13, 2004 [Page 7] Internet-Draft FLUTE Interoperabtility Testing Guidelines November 2003 contained within a single FDT. This FDT MUST be complete and MUST contain attributes of all the files transmitted during the session. At the minimum, the FDT MUST contain the TOIs and Content-Locations for all the files. However, 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 3.3. 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 multiple FDT Instances, so that the complete set of attributes describing a particular file are transmitted before the transmission of the file itself. 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 3.3 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 of different files to the respective file. At the minimum, this involves mapping the TOI and Content-Location to the respective file. o The XML schema MUST be verified. 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 a utility such as 'diff'. All the above conditions SHOULD be verified for the following cases: o The receiver joins 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. Mehta Expires May 13, 2004 [Page 8] Internet-Draft FLUTE Interoperabtility Testing Guidelines November 2003 o The receiver joins prior to the beginning of transmission of the first packet in the session, with the sending implementation using carousel for transmission. o The receiver joins the session after the first packet in the session has been transmitted, with the sending implementation using carousel for transmission. It is recommended that the sender carousel the files 3 to 10 times. 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 or more files during a session. 3.5 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 within a session. The modification of the FDT may include several scenarios. Some of the possible scenarios for instance are: o When a file is added to the transmission that was not previously to be transmitted. o When a file that was previously to be transmitted is removed from transmission. o When one or more of the attributes of one or more files, such as Content-Location, Content-Encoding etc. change. o The contents of a file are modified. 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 3.3. 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. Mehta Expires May 13, 2004 [Page 9] Internet-Draft FLUTE Interoperabtility Testing Guidelines November 2003 4. Recommended Advanced FLUTE tests This section details tests to determine interoperability under advanced or potentially difficult operating conditions. 4.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. However, the transmission occurs 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 sender IP address, the number of channels in each session, the destination IP address and port number of each of the channels in the sessions, the TSI of each of the sessions and an indication of whether or not the sessions carry packets for more than one object. Within each session, 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. Across multiple sessions, the receiver SHOULD be able to demultiplex packets and buffer them, if required, suitably based on the information from the FDT instance, the EXT_FTI information and possibly out of band information. 4.2 Interoperability for identical files across multiple session 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 Expires May 13, 2004 [Page 10] Internet-Draft FLUTE Interoperabtility Testing Guidelines November 2003 5. FDT Instance and Payload Interoperability Tests This section details tests that need to be verified to ensure that the transmission of the FDT Instances and the FDT Instance Payload are correct. The test architecture is the same as that outlined in section 3. As FDTs 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 EXT_FDT LCT extension: The HET (Header Extension Type) of the FDT Instance Header is 192. o The FDT Instance Header MUST be identical for all ALC/LCT 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). o The FDT Instance payload MUST contain an 'Expires' attribute with a valid Network Time Protocol (NTP) time value. o Each 'File' element declared under the root element 'FDT-Payload' in the FDT Instance Payload MUST contain at least the attributes 'TOI' and 'Content-Location'. Mehta Expires May 13, 2004 [Page 11] Internet-Draft FLUTE Interoperabtility Testing Guidelines November 2003 6. 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 draft. Mehta Expires May 13, 2004 [Page 12] Internet-Draft FLUTE Interoperabtility Testing Guidelines November 2003 7. Acknowledgements The author would like to thank Rod Walsh, Pasi Matilainen, Jani Peltatalo, Sami Peltatalo, Juha-Pekka Luoma and Vincent Roca for their contributions and feedback on this document. Mehta Expires May 13, 2004 [Page 13] Internet-Draft FLUTE Interoperabtility Testing Guidelines November 2003 References [1] Paila, T., Luby, M., Lehtonen, R. and V. Roca, "FLUTE - File Delivery over Unidirectional Transport", draft-ietf-rmt-flute-03 (work in progress), October 2003. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCD 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., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002. [5] Vicisano, L. and M. Luby, "Compact Forward Error Correction (FEC) Schemes", draft-ietf-rmt-bb-fec-supp-compact-01 (work in progress), May 2003. Author's Address Harsh Mehta Nokia P.O. Box 100 (Visiokatu 1) Tampere FIN-33721 Finland EMail: harsh.mehta@nokia.com Mehta Expires May 13, 2004 [Page 14] Internet-Draft FLUTE Interoperabtility Testing Guidelines 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 Mehta Expires May 13, 2004 [Page 15] Internet-Draft FLUTE Interoperabtility Testing Guidelines November 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Mehta Expires May 13, 2004 [Page 16]