INTERNET DRAFT Vish Viswanathan, Intel Corporation Dirk Koeppen, InCom GmbH Feb 26, 1999 Multicast TFTP in the Intel PXE Remote Boot Environment 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]