Internet DRAFT - draft-viswanathan-remote_boot-mtftp
draft-viswanathan-remote_boot-mtftp
INTERNET DRAFT Vish Viswanathan, Intel Corporation
Dirk Koeppen, InCom GmbH
Feb 26, 1999
Multicast TFTP in the Intel PXE Remote Boot Environment
<draft-viswanathan-remote_boot-mtftp-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.
Abstract
This document defines a protocol, Multicast Trivial File Transfer Protocol
(MTFTP), which allows several clients to simultaneously receive a file
multicast by a TFTP server as implemented in Intel's Universal Network
Boot (PXE [1]) which is part of Intel's Wired for Management Initiative
[2].
1.0 Introduction
There are some situations in which multiple clients want to download the
same file at the same time, like in the case of remote network booting of
several clients simultaneously. A typical scenario would be in the IT
department where the administrator wants to configure several machines in
an identical way at the same time. If there were individual TFTP transfers
between each client and the server, the network traffic will increase.
Also, the response from the TFTP server would be slower as it has to
support multiple connections. The MTFTP described in this internet draft
eliminates this inefficiency by multicasting the file to all the
interested clients.
1.1 Terminology
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.
Expires Aug 26, 1999 [Page 1]
< draft-viswanathan-remote_boot-mtftp-01.txt > Feb 26, 1999
Throughout this document, the words "server" or "MTFTP server" refer to a
host providing multicast TFTP services to clients.
1.2 Protocol Requirements
The following 3 things happen for a successful MTFTP transfer:
a. The MTFTP server acquires a multicast IP address to which it can send
the TFTP response packets. The mechanism through which this is achieved
is beyond the scope of this document.
b. The server passes the multicast IP address to the client. The client
listens for multicast packets on this address.
c. The client initiates a MTFTP transfer or joins one already in progress.
Steps b and c will be described in detail in the following sections.
2. Protocol Details
2.1 Querying for MTFTP specific configuration information
The client gets all the MTFTP specific configuration information from a
proxyDHCP server through the standard DHCP protocol [3] mechanism. (A
proxyDHCP server in a PXE environment is a server that provides extra
configuration information through the use of DHCP options fields.
Typically, this server does not supply IP addresses).
2.2 MTFTP specific DHCP options
A DHCP response packet from the proxyDHCP server contains all MTFTP
specific configuration information encoded in DHCP vendor specific
information option as per RFC 2132 [4].
2.2.1. DHCP Vendor specific Information Option
This option is used by clients and servers to exchange vendor specific
information. The information is an opaque object of n octets. The
Encapsulated vendor-specific options field SHOULD be encoded as a sequence
of code/length/value fields of identical syntax to the DHCP options field.
Code Len Vendor-specific information
+-----+-----+-----+-----+---
| 43 | n | i1 | i2 | ...
+-----+-----+-----+-----+---
Within the vendor specific information, we have several code/length/value
fields to specify all of the MTFTP configuration information.
Expires Aug 26, 1999 [Page 2]
< draft-viswanathan-remote_boot-mtftp-01.txt > Feb 26, 1999
2.2.1.1 Multicast IP Address Option
This option specifies the multicast IP address that is used by the client
to listen for and receive the multicast packets transmitted by the server.
The code for this option is 1 and its length is 4.
Code Len MTFTP_MULTICAST_IP_ADDRESS
+-----+-----+-----+-----+-----+-----+
| 1 | 4 | m1 | m2 | m3 | m4 |
+-----+-----+-----+-----+-----+-----+
2.2.1.2 Multicast Client UDP Port Option
This option specifies the UDP port that the client uses for the MTFTP
transfers.
The code for this option is 2 and its length is 2.
Code Len MTFTP_CLIENT_UDP_PORT
+-----+-----+-----+-----+
| 2 | 2 | c1 | c2 |
+-----+-----+-----+-----+
2.2.1.3 Multicast Server UDP Port Option
This option specifies the UDP port that the server uses for the MTFTP
transfers. The client MUST send its MTFTP requests to this port on the
server.
The code for this option is 3 and its length is 2.
Code Len MTFTP_SERVER_UDP_PORT
+-----+-----+-----+-----+
| 3 | 2 | s1 | s2 |
+-----+-----+-----+-----+
2.2.1.4 Multicast Transfer Start Delay Option
This options specifies, in seconds, the amount of time a client should
wait before initiating a MTFTP transfer.
The code for this option is 4 and its length is 1.
Code Len MTFTP_TRANSMISSION_START_DELAY
+-----+-----+-----+
| 4 | 1 | t1 |
+-----+-----+-----+
Expires Aug 26, 1999 [Page 3]
< draft-viswanathan-remote_boot-mtftp-01.txt > Feb 26, 1999
2.2.1.5 Multicast Transfer Timeout Option
This options specifies, in seconds, the amount of time a client should
wait before re-sending a MTFP request.
The code for this option is 5 and its length is 1.
Code Len MTFTP_TRANSFER_TIMEOUT
+-----+-----+-----+
| 5 | 1 | t1 |
+-----+-----+-----+
3. Multicast Trivial File Transfer Protocol Details
This protocol is exactly the same as the standard TFTP protocol [5] but
for a simple difference. All the TFTP responses from the server MUST be
directed to the multicast IP address (MTFTP_MULTICAST_IP_ADDRESS) as the
destination IP address. This enables multiple clients to listen and
receive the same packet that is transmitted by the server.
3.1 Different Stages of A MTFTP Transfer
A client goes through the following 3 stages during a MTFTP transfer.
. MTFTP Open
. MTFTP Receive
. MTFTP Close
3.1.1 MTFTP Open
Any client wishing to download a file through MTFTP first determines
whether there is a multicast TFTP transfer already in progress for the
file that it wants to download. (The MTFTP server MUST use a unique
multicast address for each of the files that it can support in a MTFTP
transfer). The client, after binding to the port MTFTP_CLIENT_UDP_PORT,
waits for MTFTP_TRANSMISSION_START_DELAY seconds to see whether there are
any packets addressed to the MTFTP_MULTICAST_IP_ADDRESS. Depending on
whether there is a response or not, the client follows different steps as
explained in the next 2 sections.
Expires Aug 26, 1999 [Page 4]
< draft-viswanathan-remote_boot-mtftp-01.txt > Feb 26, 1999
3.1.1.1 Multicast transfer already in progress
If the client receives a response packet within the
MTFTP_TRANSMISSION_START_DELAY period, then a multicast transfer is
already in progress. The client starts receiving the packets and stores
them in an internal list (or uses some other mechanism to keep track of
the received packets). As this client is not the one to initiate the
original transfer, it MUST not send a TFTP ACK packet to any of the
received packets. When the file transfer finishes (this happens when the
TFTP server sends the last block of data of the file), the client would
only have received the ending portion of the file. All the beginning
blocks of the file were missed by this client, when it joined a multicast
transfer which was in progress already. We will discuss how to receive the
rest of the file in the section under "MTFTP Receive".
3.1.1.2 No multicast transfer in progress
If the client does not receive any packets during the initial
MTFTP_TRANSMISSION_START_DELAY period, then it assumes that there is no
multicast transfer in progress at that time. At the end of this period,
the client requests the server to start a new transfer. This is done by
the client sending a regular TFTP open packet (opcode set to 1). However,
this packet is sent to the server's MTFTP_SERVER_UDP_PORT so that the
server knows that it is a multicast TFTP request versus a standard TFTP
request.
3.1.1.3 How the server deals with the MTFTP_OPEN request
When the server receives a MTFTP_OPEN request on its
MTFTP_SERVER_UDP_PORT, it checks to make sure that a transfer is not
already in progress. If there is a transfer already in progress for the
requested file, then the server ignores this request. The client soon
starts to receive some block of the file transfer that is in progress on
its MTFTP_CLIENT_UDP_PORT. However, if there is no transfer in progress,
then the server unicasts a response back to the client for the first data
packet and also follows that by multicasting the same packet so that all
other interested clients can also receive that.
3.1.4 MTFTP Receive
As mentioned in the previous section, the first packet of a multicast
transfer MUST always be sent both as unicast and multicast UDP packets.
Subsequent packets are only multicast. The recipient of the first unicast
packet becomes the master client that would acknowledge each received
packet. The master client (i.e the acknowledging client) MUST acknowledge
all the packets even if that client has received the entire file. A server
MUST always transmit the complete file. Therefore, clients that start
listening to a transfer part way through can wait and then get the rest of
the file on the next MTFTP transfer to make up for what was missed during
the first time.
Expires Aug 26, 1999 [Page 5]
< draft-viswanathan-remote_boot-mtftp-01.txt > Feb 26, 1999
3.1.5. MTFTP Close
A MTFTP transfer is finished when the acknowledging client has received
all packets and disconnects. Clients who joined the transfer part way
through the transfer can initiate a new transfer if one has not already
started. In case there are multiple clients who joined part way through,
then there is an algorithm to minimize the number of clients
simultaneously trying to initiate a new transfer. Before a new transfer is
started, there is a calculated delay. An algorithm based on the number of
packets received modifies the default delay of
MTFTP_TRANSMISSION_START_DELAY seconds. Clients who received fewer packets
(because of the faster transfer rate of the server) wait for a shorter
time than those who received more. This algorithm ensures that
* Slower clients define the transmission speed as they are more likely to
become the acknowledging clients.
* Clients with a large number of received packets may disconnect from the
transfer after they received all missing packets as they are less likely
to become acknowledging clients.
References:
[1] Preboot Execution Environment (PXE) Specification Version 2.0
ftp://download.intel.com/ial/wfm/pxespec.pdf
[2] Intel's Wired for Management Initiative,
URL:http://developer.intel.com/ial/wfm/index.htm
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
1997.
[4] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
Extension", RFC 2132, March 1997.
[5] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, June 1981.
Expires Aug 26, 1999 [Page 6]
< draft-viswanathan-remote_boot-mtftp-01.txt > Feb 26, 1999
Authors' Addresses
Vish Viswanathan
Intel Corporation, MS JF3-206
5200 NE Elam Young Pkwy
Hillsboro, OR 97124
Phone: (503) 264-9693
Email: vish.viswanathan@intel.com
Dirk Koeppen
InCom GmbH
Holzwiesenweg 22
D-63073 Offenbach, Germany
Phone: (011) 49 69 89 3000
Email: dirk@incom.de
Expires Aug 26, 1999 [Page 7]
