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
<draft-rfced-exp-yung-00.txt>
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