293 lines
12 KiB
Plaintext
293 lines
12 KiB
Plaintext
|
ftp://ds.internic.net/rfc/rfc2090.txt
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group A. Emberson
|
|||
|
|
Request for Comments: 2090 Lanworks Technologies Inc.
|
|||
|
|
Category: Experimental February 1997
|
|||
|
|
|
|||
|
|
|
|||
|
|
TFTP Multicast Option
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo defines an Experimental Protocol for the Internet
|
|||
|
|
community. This memo does not specify an Internet standard of any
|
|||
|
|
kind. Discussion and suggestions for improvement are requested.
|
|||
|
|
Distribution of this memo is unlimited.
|
|||
|
|
|
|||
|
|
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 clients 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:
|
|||
|
|
|
|||
|
|
+--------+----~~----+---+--~~--+---+-----------+---+---+
|
|||
|
|
| opc=1 | filename | 0 | mode | 0 | multicast | 0 | 0 |
|
|||
|
|
+--------+----~~----+---+--~~--+---+-----------+---+---+
|
|||
|
|
|
|||
|
|
opc
|
|||
|
|
The opcode field contains a 1, for Read Requests, as defined
|
|||
|
|
in [1].
|
|||
|
|
|
|||
|
|
|
|||
|
|
Emberson Experimental [Page 1]
|
|||
|
|
|
|||
|
|
|
|||
|
|
RFC 2090 TFTP Multicast Option February 1997
|
|||
|
|
|
|||
|
|
|
|||
|
|
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).
|
|||
|
|
|
|||
|
|
+-------+-----------+---+-------~~-------+---+
|
|||
|
|
| opc | 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.
|
|||
|
|
|
|||
|
|
port
|
|||
|
|
The port field contains the destination port of the multicast
|
|||
|
|
packets. The use of Registered Port number 1758 (tftp-mcast)
|
|||
|
|
is recommended. 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.
|
|||
|
|
|
|||
|
|
|
|||
|
|
Emberson Experimental [Page 2]
|
|||
|
|
|
|||
|
|
|
|||
|
|
RFC 2090 TFTP Multicast Option February 1997
|
|||
|
|
|
|||
|
|
|
|||
|
|
Data Transfer
|
|||
|
|
|
|||
|
|
After the OACK is received by the client it will send an ACK for
|
|||
|
|
packet zero, as in [2]. With the multicast option being accepted this
|
|||
|
|
ACK will indicate to the server that the client wants the first
|
|||
|
|
packet. In other words the ACKs may now be seen as a request for the
|
|||
|
|
n+1th block of data. This enables each a client to request any block
|
|||
|
|
within the file that it may be missing.
|
|||
|
|
|
|||
|
|
To manage the data transfer the server will maintain a list of
|
|||
|
|
clients. Typically the oldest client on the list, from here on
|
|||
|
|
referred to as the Master Client, will be responsible for sending
|
|||
|
|
ACKs. When the master client is finished, the server will send
|
|||
|
|
another OACK to the next oldest client, telling it to start sending
|
|||
|
|
ACKs. Upon receipt of this OACK the new master client will send an
|
|||
|
|
ACK for the block immediately before the first block required to
|
|||
|
|
complete its download.
|
|||
|
|
|
|||
|
|
Any subsequent clients can start receiving blocks of a file during a
|
|||
|
|
transfer and then request any missing blocks when that client becomes
|
|||
|
|
the master client. When the current master client is finished, the
|
|||
|
|
server will notify the next client with an OACK making it the new
|
|||
|
|
master client. The new master client can start requesting missed
|
|||
|
|
packets. Each client must terminate the transfer by sending an
|
|||
|
|
acknowledgment of the last packet or by sending an error message to
|
|||
|
|
server. This termination can occur even if the client is not the
|
|||
|
|
master client.
|
|||
|
|
|
|||
|
|
Any subsequent OACKs to a client may have an empty multicast address
|
|||
|
|
and port fields, since this information will already be held by that
|
|||
|
|
client. In the event a client fails to respond in a timely manner to
|
|||
|
|
a OACK enabling it as the master client, the server shall select the
|
|||
|
|
next oldest client to be the master client. The server shall
|
|||
|
|
reattempt to send a OACK to the non- responding client when the new
|
|||
|
|
master client is finished. The server may cease communication with a
|
|||
|
|
client after a reasonable number of attempts.
|
|||
|
|
|
|||
|
|
Each transfer will be given a 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 using the same port as will be used for sending the
|
|||
|
|
multicast data packets.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Emberson Experimental [Page 3]
|
|||
|
|
|
|||
|
|
|
|||
|
|
RFC 2090 TFTP Multicast Option February 1997
|
|||
|
|
|
|||
|
|
|
|||
|
|
At any point if a client, other than the master client, sends a ACK
|
|||
|
|
to the server, the server will respond with another OACK with the mc
|
|||
|
|
field holding a value of zero. 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.
|
|||
|
|
|
|||
|
|
The server may also send unicast packets to a lone client to reduce
|
|||
|
|
adverse effects on other machines. As it is possible that machines
|
|||
|
|
may be forced to process many extraneous multicast packets when
|
|||
|
|
attempting to receive a single multicast address.
|
|||
|
|
|
|||
|
|
Example
|
|||
|
|
|
|||
|
|
clients server message
|
|||
|
|
------------------------------------------------------------
|
|||
|
|
1 C1 |1|afile|0|octet|0|multicast|0|0| -> RRQ
|
|||
|
|
2 C1 <- |6|multicast|224.100.100.100,1758,1| OACK
|
|||
|
|
3 C1 |4|0| -> ACK
|
|||
|
|
4 M <- |3|1|1| 512 octets of data| DATA
|
|||
|
|
5 C1 |4|1| -> ACK
|
|||
|
|
6 M <- |3|2|1| 512 octets of data| DATA
|
|||
|
|
7 C2 |1|afile|0|octet|0|multicast|0|0| -> RRQ
|
|||
|
|
8 C2 <- |6|multicast|224.100.100.100,1758,0| OACK
|
|||
|
|
9 C2 |4|0| -> ACK
|
|||
|
|
10 C1 |4|2| -> ACK
|
|||
|
|
11 M <- |3|3|1| 512 octets of data| DATA
|
|||
|
|
12 C3 |1|afile|0|octet|0|multicast|0|0| -> RRQ
|
|||
|
|
13 C3 <- |6|multicast|224.100.100.100,1758,0| OACK
|
|||
|
|
14 C1 |4|3| -> ACK
|
|||
|
|
15 C2 |4|0| -> ACK
|
|||
|
|
16 M (except C2) <- |3|4|1| 512 octets of data| DATA
|
|||
|
|
17 C1 |4|4| -> ACK
|
|||
|
|
18 M <- |3|5|1| 512 octets of data| DATA
|
|||
|
|
19 C1 |4|5| -> ACK
|
|||
|
|
20 M <- |3|6|1| 100 octets of data| DATA
|
|||
|
|
21 C1 |4|6| -> ACK
|
|||
|
|
22 C2 <- |6|multicast|,,1| OACK
|
|||
|
|
23 C2 |4|0| -> ACK
|
|||
|
|
24 M <- |3|1|1| 512 octets of data| DATA
|
|||
|
|
25 C2 |4|1| -> ACK
|
|||
|
|
26 M <- |3|2|1| 512 octets of data| DATA
|
|||
|
|
27 C2 |4|3| -> ACK
|
|||
|
|
28 M <- |3|4|1| 512 octets of data| DATA
|
|||
|
|
29 C2 |4|6| -> ACK
|
|||
|
|
30 C3 <- |6|multicast|,,1| OACK
|
|||
|
|
31 C3 |4|2| -> ACK
|
|||
|
|
32 M <- |3|3|1| 512 octets of data| DATA
|
|||
|
|
33 C3 |4|6| -> ACK
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Emberson Experimental [Page 4]
|
|||
|
|
|
|||
|
|
|
|||
|
|
RFC 2090 TFTP Multicast Option February 1997
|
|||
|
|
|
|||
|
|
|
|||
|
|
Comments:
|
|||
|
|
1 request from client 1
|
|||
|
|
2 option acknowledgment
|
|||
|
|
3 acknowledgment for option acknowledgment,
|
|||
|
|
or request for first block of data
|
|||
|
|
4 first data packet sent to the multicast address
|
|||
|
|
7 request from client 2
|
|||
|
|
8 option acknowledgment to client 2,
|
|||
|
|
send no acknowledgments
|
|||
|
|
9 OACK acknowledgment from client 2
|
|||
|
|
15 OACK acknowledgment from client 3
|
|||
|
|
16 client 2 fails to receive a packet
|
|||
|
|
21 client 1 acknowledges receipt of the last block,
|
|||
|
|
telling the server it is done
|
|||
|
|
23 option acknowledgment to client 2,
|
|||
|
|
now the master client
|
|||
|
|
25 client 2 acknowledging with request for first block
|
|||
|
|
27 client 2 acknowledges with request for missed block
|
|||
|
|
29 client 2 signals it is finished
|
|||
|
|
31 client 3 is master client and asks for missing blocks
|
|||
|
|
33 client 3 signals it is finished
|
|||
|
|
|
|||
|
|
Conclusion
|
|||
|
|
|
|||
|
|
With the use of the multicast and blocksize[3] options TFTP will be
|
|||
|
|
capable of fast and efficient downloads of data. Using TFTP with the
|
|||
|
|
multicast option will maintain backward compatibility for both
|
|||
|
|
clients 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.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Emberson Experimental [Page 5]
|
|||
|
|
|
|||
|
|
|
|||
|
|
RFC 2090 TFTP Multicast Option February 1997
|
|||
|
|
|
|||
|
|
|
|||
|
|
Author's Address
|
|||
|
|
|
|||
|
|
A. Thomas Emberson
|
|||
|
|
Lanworks Technologies, Inc.
|
|||
|
|
2425 Skymark Avenue
|
|||
|
|
Mississauga, Ontario
|
|||
|
|
Canada L4W 4Y6
|
|||
|
|
|
|||
|
|
|
|||
|
|
Phone: (905) 238-5528
|
|||
|
|
EMail: tom@lanworks.com
|
|||
|
|
|
|||
|
|
|
|||
|
|
Emberson Experimental [Page 6]
|
|||
|
|
|