INTERNET DRAFT EXPIRES NOV 1998 INTERNET DRAFT Network Working Group W. C. Yung INTERNET DRAFT Lanworks Technologies Inc. Obsoletes: RFC 2090 April 1998 Category: Experimental TFTP Multicast Option Status of This Memo This document is an Internet-Draft. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Acknowledgements The protocol, as defined in [4], was originally designed by A. Thomas Emberson. The current revision of the document includes modifications of the interaction between a TFTP server and clients after the first data transfer. The re-request scheme was also redesigned to give a high priority to the slower client on a network. Abstract The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a new TFTP option. This new option will allow the multiple client to receive the same file concurrently through the use of Multicast packets. The TFTP Option Extension mechanism is described in [2]. Often when similar computers are booting remotely they will each download the same image file. By adding multicast into the TFTP option set, two or more computers can download a file concurrently, thus increasing network efficiency. This document assumes that the reader is familiar with the terminology and notation of both [1] and [2]. Multicast Option Specification The TFTP Read Request packet is modified to include the multicast option as follows: Yung [Page 1] +--------+----~~----+---+--~~--+---+-----------+---+---+ | opc=1 | filename | 0 | mode | 0 | multicast | 0 | 0 | +--------+----~~----+---+--~~--+---+-----------+---+---+ opc The opcode field contains a 1, for Read Requests, as defined in [1]. filename The name of the file to be read, as defined in [1]. This is a NULL-terminated field. mode The mode of the file transfer: "netascii", "octet", or "mail", as defined in [1]. This is a NULL-terminated field. multicast Request for multicast transmission of the file option, "multicast" (case insensitive). This is a NULL-terminated field. The value for this option request is a string of zero length. If the server is willing to accept the multicast option, it sends an Option Acknowledgment (OACK) to the client including the multicast option, as defined in [2]. The OACK to the client will specify the multicast address and flag to indicate whether that client should send block acknowledgments (ACK). The exchange of the multicast information will by default uses registered port 1758 for server, and registered port 1759 for client. +--------+-----------+---+-------~~-------+---+ | opc=6 | multicast | 0 | addr, port, mc | 0 | +--------+-----------+---+-------~~-------+---+ opc The opcode field contains the number 6, for Option Acknowledgment, as defined in [2]. multicast Acknowledges the multicast option. This is a NULL-terminated field. addr The addr field contains the multicast IP address. This field is terminated with a comma. Yung [Page 2] port The port field contains the destination port of the multicast packets. This field is terminated with a comma. mc This field will be either 0 or 1, to tell the client whether it is the master client, that is, it is responsible for sending ACKs to the server. This is NULL-terminated field. Data Transfer After the OACK is received by a client, it will send an ACK for packet zero to the assigned multicast IP address if the mc field is set to 1. With the mc field holding a value of 1, the OACK indicates to the client that it is the first client requesting this file, and it is the master client as well. Also with the multicast option being accepted, the ACK indicates to the server that the client wants the first packet. For any subsequent clients requesting for the same file, the server will respond with an OACK which is identical to the one for the master client, except for the mc field which will hold a value of 0 instead of 1. Upon finish exchanging the multicast information, clients can begin to receive data packets immediately without sending any ACKs for the following received data packets. To manage the data transfer, the server will maintain a list of clients requesting for the same file. Server uses the list only for switching master client in case the current master client fails to acknowledge the received packets. Typically when the server finishes one complete file transfer, it will wait for a random period for any new request of the same file before it leave the assigned multicast IP address. It is the client's responsibility to re-request a new transmission if there are still some packets missing. The server shall not initiate any new data transfer. If there are clients still missing some packets after one data transfer, they will all delay for a short period before the next RRQs are sent. The delay is a decreasing function of the number of missing packets and increasing function of the number of packets received. This design is laid out in such way that the slower client should be always given a greater opportunity to be the acknowledging client. In other words, the more packets that a client has received, the faster the client is likely to be, and vice versa. Yung [Page 3] In the event of the master client failing to acknowledge a received packet after several attempts, the server will take the next client, if there is one, from the list, and send an OACK with the mc field holding a value of 1, the multicast IP address and port fields blank. The server assumes the client has already held the information about multicast address and port number of the data transfer. Each different file transfer will be given a different multicast address for use to distribute the data packets. Since there can be multiple servers on a given network or a limited number of addresses available to a given server, it is possible that their might be more than one transfer using a multicast address. To ensure that a client only accepts the correct packets, each transfer must use a unique port on the server. The source IP address and port number will identify the data packets for the transfer. Thus the server must send the unicast OACK packet to the client first, and the server will start sending data packets to the client using the assigned port once an ACK is received from a client. At any point during a data transfer, other than the master client, sends an ACK to the server, the server will respond with another OACK with the mc field holding a value of 0. If this client persists in sending erroneous ACKs, the server may send an error packet to the client, discontinuing the file transfer for that client. Example clients server message ---------------------------------------------------------------- 1 C1 |1|afile|0|octet|0|multicast|0|0| -> RRQ 2 C1 <- |6|multicast|244.0.0.2,6901,1| OACK 3 C1 |4|0| -> M ACK 4 M <- |3|1|512 octets of data| DATA 5 C1 |4|1| -> M ACK 6 M <- |3|2|512 octets of data| DATA 7 C2 |1|afile|0|octet|0|multicast|0|0| -> RRQ 8 C2 <- |6|multicast|244.0.0.2,6901,0| OACK 9 C1 |4|2| -> M ACK 10 M <- |3|3|512 octets of data| DATA 11 C1 |4|3| -> M ACK 12 C3 |1|afile|0|octet|0|multicast|0|0| -> RRQ 13 C3 <- |6|multicast|244.0.0.2,6901,0| OACK 14 M <- |3|4|512 octets of data| DATA Yung [Page 4] 15 C1 |4|4| -> M ACK 16 M <- |3|5|512 octets of data| DATA 17 C1 |4|5| -> M ACK 18 M <- |3|6|512 octets of data| DATA 19 M <- |3|6|512 octets of data| DATA 20 M <- |3|6|512 octets of data| DATA 21 C2 <- |6|multicast|,,1| OACK 22 C2 |4|6| -> M ACK 23 M <- |3|7|512 octets of data| DATA 24 C2 |4|7| -> M ACK 25 M <- |3|8|100 octets of data| DATA 26 C2 |4|8| -> M ACK 27 C3 |1|afile|0|octet|0|multicast|0|0| -> RRQ 28 C3 <- |6|multicast|244.0.0.2,6901,1| OACK 29 C3 |4|0| -> M ACK 30 C2 |1|afile|0|octet|0|multicast|0|0| -> RRQ 31 C2 <- |6|multicast|244.0.0.2,6901,0| OACK 32 M <- |3|1|512 octets of data| DATA 33 C3 |4|1| -> M ACK 34 M <- |3|2|512 octets of data| DATA 35 C3 |4|2| -> M ACK 36 M <- |3|3|512 octets of data| DATA 37 C3 |4|3| -> M ACK 38 M <- |3|4|512 octets of data| DATA 39 C3 |4|4| -> M ACK 40 M <- |3|5|512 octets of data| DATA 41 C3 |4|5| -> M ACK 42 M <- |3|6|512 octets of data| DATA 43 C3 |4|6| -> M ACK 44 M <- |3|7|512 octets of data| DATA 45 C3 |4|7| -> M ACK 46 M <- |3|8|100 octets of data| DATA 47 C3 |4|8| -> M ACK Comments: 1 request from client 1 2 option acknowledgment to client 1 with mc field holding a value of 1 3 acknowledgment for option acknowledgment, or request for first block 4 first data packet sent to the multicast address 7 request from client 2 8 option acknowledgment to client 2 with mc field holding a value of 0 9 ACK acknowledgment of block # 2 from client 1 to the multicast address 12 request from client 3 Yung [Page 5] 13 option acknowledgment to client 2 with mc field holding a value of 0 18, 19, 20 server attempts 3 times if client 1 fails to acknowledge 21 server switch master client from client 1 to client 2 22 client 2 assumes the job to respond to the server 27, 30 client 3 re-request a file transfer after finding some packets still missing from the first data transfer. client 3 misses more packets than client 2, therefore client 3 is the master client for the next data transfer 47 client 3 signals it received the last data packet of the transfer Conclusion With the use of the multicast and blocksize [3] options, TFTP will be capable of fast and efficient downloading data. Using TFTP with the multicast option will maintain backward compatibility for both client and servers. Security Considerations Security issues are not discussed in this memo. References [1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, MIT, July 1992. [2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC 1782, Xylogics, Inc., Hewlett Packard Co., March 1995. [3] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 1783, Xylogics, Inc., Hewlett Packard Co., March 1995. [4] A. Thomas Emberson, "TFTP Multicast Option", RFC 2090, Lanworks Technologies, Inc. February 1997. Yung [Page 6] Author's Address Weng-Chin (Winson) Yung Lanworks Technologies CO. a subsidiary of 3Com Corporation 2425 Skymark Avenue Mississagua, Ontario Canada L4W 4Y6 Phone: (905) 238-5528 EMail: winson_yung@ne.3com.com Yung [Page 7] Full Copyright Statement Copyright (C) The Internet Society (1997). 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 implmentation 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 assigns. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." INTERNET DRAFT EXPIRES NOV 1998 INTERNET DRAFT