INTERNET-DRAFT M. Johnston expires: December, 2003 Intel Corporation July, 2003 TFTP Multicast Definition draft-johnston-tftp-multicast-02.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 Copyright Notice Copyright (C) The Internet Society (2002, 2003). All rights reserved. Abstract This document defines a backwards compatible multicast extension to TFTP (multicast TFTP or MTFTP, for short). MTFTP is a way for a server to download one image to multiple clients at the same time, potentially reducing the network load and overall download time. M. Johnston draft-johnston-tftp-multicast-02.txt [Page 1] Internet Draft TFTP Multicast Option July, 2003 Table of Contents Status of This Memo......................................1 Copyright Notice.........................................1 Abstract.................................................1 Table of Contents........................................2 1 Introduction..........................................3 1.1 Specification.....................................3 2 Protocol Overview.....................................3 3 Packet Information....................................4 3.1 TFTP OpCodes......................................4 3.2 Read Request (RRQ)................................4 3.3 Data Packet (DATA)................................5 3.4 Option Acknowledgement Packet (OACK)..............6 3.5 Acknowledgement Packet (ACK)......................6 3.6 Error Packet (ERROR)..............................7 4 TFTP Options..........................................7 4.1 "tsize" Option....................................7 4.2 "blksize" Option..................................7 4.3 "bigblk#" Option..................................7 4.4 "stream" Option...................................8 5 Network Traffic Examples..............................8 5.1 Server Does Not Have Option Extension Support.....8 5.2 Server Does Not Have Multicast Support............8 5.3 Server Has Multicast Support......................9 6 Security Considerations..............................10 7 References...........................................10 8 Author's Address.....................................10 9 Full Copyright Statement.............................11 M. Johnston draft-johnston-tftp-multicast-02.txt [Page 2] Internet Draft TFTP Multicast Option July, 2003 1 Introduction The main reasons to use MTFTP are to reduce the amount of network traffic and time spent downloading when sending the same, generally large, file image from the server to multiple clients. Instead of having every client connect to the server with a separate TFTP session, a multicast session permits one transfer to be received by multiple clients. The MTFTP protocol extensions introduced here permit the server to choose between a TFTP or MTFTP session. MTFTP is a read-only protocol. Images are transferred from a server to multiple clients (downloaded) but cannot be transferred from a client to multiple servers (uploaded). The protocol reduces network traffic through a one to many multicast packet transfer while providing robustness through a simple restart capability. In order to reduce the number of collisions, reduce the number of missed DATA packets and keep from saturating the network with traffic, the server enforces a negotiable minimum delay period between consecutive DATA packets. 1.1 Specification In this specification, the key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC2119. 2 Protocol Overview To initiate a MTFTP session, a group of clients subscribing to the MTFTP service will send a read-request (RRQ) packet with MTFTP options to a server. The server determines if a multicast session is appropriate. The server sends an option-acknowledgement (OACK) indicating the transfer mode. In addition, one client selected at random will be designated 'active'. The server and 'active' client will drive the multicast session while the remaining 'passive' clients continue collecting data packets. When the multicast session is initiated, one of the parameters specified is a 'timeout' used by the server and all of the clients in the session. In addition, the clients maintain a random jitter timeout that they select within a half-window of the timeout value. Clients use these values to permit the 'active' client effective M. Johnston draft-johnston-tftp-multicast-02.txt [Page 3] Internet Draft TFTP Multicast Option July, 2003 priority to drive the protocol. If the 'active' client falters, then 'passive' clients random jitter timeouts permit 'passive' clients to issue read-requests. The server collects these read-request, selects one at random, and continues the session. At the conclusion of the 'active' client session, there is a time window that allows 'passive' clients to restart the session using the same MTFTP options. When a 'passive' client resumes, it is promoted to 'active' while the old 'active' client session is terminated. The new 'active' client resumes the session at the last packet that was acknowledged by the old 'active' client. 3 Packet Information This section describes the TFTP packet types and options used by clients and servers implementing MTFTP. Detailed information about the packet fields and options not covered in this document can be found in [1] and [2]. 3.1 TFTP OpCodes Below is the list of commonly used TFTP opcodes as of the writing of this document. RRQ 1 [1] WRQ 2 [1] (Not used by MTFTP clients.) DATA 3 [1] ACK 4 [1] ERROR 5 [1] OACK 6 [2] 3.2 Read Request (RRQ) 2-bytes string string string string -------------------------------------------------------------- | OpCode | Filename | 0 | Mode | 0 | Option | 0 | Value | 0 | -------------------------------------------------------------- A group of clients subscribing to the MTFTP server MUST include two multicast option strings: "multicast" and "timeout". Like other TFTP option strings [2] [3] [6], these strings are not case dependent and MUST be paired with a value string. The "multicast" value string sent by the client MUST be set to "0". The server will return a multicast IP address, UDP M. Johnston draft-johnston-tftp-multicast-02.txt [Page 4] Internet Draft TFTP Multicast Option July, 2003 port number and an 'active/passive' flag in the OACK packet. Legal values for the "timeout" value string are discussed in [2]. Suggested "timeout" values for multicast clients are "1", "2" and "3" seconds. The server MAY increase the "timeout" value in the OACK packet. All clients compute a "restart-delay" value representing the number of milliseconds that 'passive' listening clients MUST wait before attempting to resume a dropped MTFTP session by sending a RRQ packet with the options received in the OACK packet to the server on the OACK packet source UDP port. The "restart-delay" value is a random number in the interval of (0, timeout/2]. In this case, the timeout value MUST be the updated value as directed in the OACK packet from the server. ALL 'passive' clients MUST start their "restart-delay" timer after the 'timeout' timer has expired. If a 'passive' client's "restart-delay" timer expires, the client SHOULD send a new RRQ packet to the server at the OACK packet UDP source port. 3.3 Data Packet (DATA) 2-bytes 2-bytes n-bytes ----------------------------- | OpCode | Block# | Data | ----------------------------- If the server does not support TFTP option extensions, does not support MTFTP or determines that the file is not large enough to benefit from using multicast, the server MAY respond to the client's RRQ packet with a unicast DATA packet. The client MAY elect to continue a normal TFTP download, as defined in [1], or terminate the session by sending a 'TFTP option error' ERROR packet [2]. When multicasting, the Block number MUST NOT roll over to zero. This is an error and the session MUST be terminated by sending an 'Illegal TFTP operation' ERROR packet [1]. During a multicast session all DATA packets transmitted by the server are multicasted to the client's multicast listening port returned in the OACK packet. A multicast server MUST never send (or re-send) a DATA packet until it first receives an ACK or OACK packet from the 'active' client. M. Johnston draft-johnston-tftp-multicast-02.txt [Page 5] Internet Draft TFTP Multicast Option July, 2003 3.4 Option Acknowledgement Packet (OACK) 2-bytes string string ----------------------------------- | OpCode | Option | 0 | Value | 0 | ----------------------------------- If the server does not support MTFTP, determines that the file is not large enough to benefit from MTFTP or determines that the client or connection is too slow or unreliable for MTFTP; it may respond to the client's RRQ packet with an OACK packet that does not contain the multicast options. The client may elect to continue a normal TFTP download or terminate the session by sending a 'TFTP option error' ERROR packet [2]. If the server does decide to use MTFTP it must copy the client's option strings verbatim from the RRQ packet to the OACK packet, as defined in [2]. The server may adjust the value string contents. The "multicast" value string returned by the server contains three comma separated fields: The multicast IP address, the client's multicast UDP listening port and the 'active/passive' flag. Two examples of this string are: "246.6.6.6,1234,1" and "242.13.13.13,2345,0" If the 'active'/'passive' flag is zero (as shown in the second example string), the client is 'passive' and must not send an ACK or ERROR packet to the server. If the flag is one, the client is 'active' and it must send an ACK or ERROR packet to the server. Any values other than zero or one are invalid and the client must send a 'TFTP option error' ERROR packet to the server. The OACK packet is sent unicast to the client's listening port. 'Passive' clients MUST note the source port of the OACK packet. In order to resume a MTFTP session, a 'passive' client MUST send a new RRQ packet to the source port of the OACK packet. 3.5 Acknowledgement Packet (ACK) 2-bytes 2-bytes ------------------- | OpCode | Block# | -------------------- M. Johnston draft-johnston-tftp-multicast-02.txt [Page 6] Internet Draft TFTP Multicast Option July, 2003 The 'active' client MUST acknowledge every received DATA packet. If the 'active' client's receive "timeout" expires, it SHOULD re-send the ACK packet several times before terminating the session. The 'active' client may assume that an ACK packet was dropped and resend ACK packets before the receive "timeout" expires. Care should be taken not to resend ACK packets too quickly so DATA and ACK packets are not crossing each other on the network. The server MUST only respond to the 'active' client's ACK packets with DATA packets. The server MUST respond to all non-'active' client ACK packets with either an OACK packet (identifying the client as 'passive') or an ERROR packet. 3.6 Error Packet (ERROR) 2-bytes 2-bytes string ----------------------------------- | OpCode | ErrorCode | Message | 0 | ----------------------------------- No new ErrorCode values are defined in this document. 4 TFTP Options MTFTP is designed to operate with the other existing and known draft TFTP options. In most cases little or no changes are required in the 'passive' MTFTP client operation. 4.1 "tsize" Option This option works as defined in [6]. It does not affect 'passive' client operation. 4.2 "blksize" Option This option works as defined in [3], but is limited to the MTU between the server and the client. It does not affect 'passive' client operation. 4.3 "bigblk#" Option M. Johnston draft-johnston-tftp-multicast-02.txt [Page 7] Internet Draft TFTP Multicast Option July, 2003 This option works as defined in the TFTP big block number option draft. It has a minor effect on 'passive' client operation. 'Passive' clients must check the TFTP op-code in the multicast DATA packets to determine if the DATA packets being received contain two-byte or eight-byte packet numbers. 4.4 "stream" Option This option works as defined in the TFTP streaming option draft. It has a minor effect on both 'active' and 'passive' client operation. Clients must be prepared to receive multicast DATA packets out of order. 5 Network Traffic Examples 5.1 Server Does Not Have Option Extension Support In this example, the client sends a RRQ with the multicast option. The server does not have TFTP option support and replies with a DATA packet. The client completes a standard TFTP download [1]. client server ----------------------------------------------------------- |1|foofile|0|octet|0|multicast|0|0|0| |timeout|0|1|0| --> RRQ <-- |3|1| n octets of data | DATA |4|1| --> ACK <-- |3|2| n octets of data | DATA |4|2| --> ACK <-- |3|3| ACK 5.2 Server Does Not Have Multicast Support In this example, the client sends a RRQ with the multicast option. The server does not have multicast support and replies with an OACK packet that does not contain the multicast option. The client completes a standard TFTP download with options [2]. client server ----------------------------------------------------------- M. Johnston draft-johnston-tftp-multicast-02.txt [Page 8] Internet Draft TFTP Multicast Option July, 2003 |1|foofile|0|octet|0|multicast|0|0|0| |timeout|0|1|0| --> RRQ <-- |6|timeout|0|2|0| OACK |4|0| --> ACK <-- |3|1| n octets of data | DATA |4|1| --> ACK <-- |3|2| n octets of data | DATA |4|2| --> ACK <-- |3|3| ACK 5.3 Server Has Multicast Support In this example, three clients send RRQ packets with the multicast option. The server selects one to be the 'active' client and the other two to be 'passive' clients. The third client starts late and has to start a second session to get the complete set of data. client server ----------------------------------------------------------- #1 |1|foofile|0|octet|0|multicast|0|0|0| |timeout|0|2|0| --> RRQ #2 |1|foofile|0|octet|0|multicast|0|0|0| |timeout|0|1|0| --> RRQ #1 <-- |6|multicast|0|246.6.6.6,1234,1|0| |timeout|0|2|0| OACK #2 <-- |6|multicast|0|246.6.6.6,1234,0|0| |timeout|0|2|0| OACK #1 |4|0| --> ACK MC <-- |3|1| n octets of data | DATA #1 |4|1| --> ACK #3 |1|foofile|0|octet|0|multicast|0|0|0| |timeout|0|2|0| --> RRQ #3 <-- |6|multicast|0|246.6.6.6,1234,0|0| |timeout|0|2|0| OACK MC <-- |3|2| n octets of data | DATA #1 |4|2| --> ACK MC <-- |3|3| n octets of data | DATA #1 |4|3| --> ACK MC <-- |3|4| n octets of data | DATA #1 |4|4| --> ACK MC <-- |3|5| ACK #3 |1|foofile|0|octet|0|multicast|0|0|0| |timeout|0|2|0| --> RRQ #3 <-- |6|multicast|0|246.6.6.6,1234,1|0| |timeout|0|2|0| OACK #3 |4|0| --> ACK MC <-- |3|1| n octets of data | DATA M. Johnston draft-johnston-tftp-multicast-02.txt [Page 9] Internet Draft TFTP Multicast Option July, 2003 #3 |4|1| --> ACK MC <-- |3|2| n octets of data | DATA #3 |4|2| --> ACK MC <-- |3|3| n octets of data | DATA #3 |4|3| --> ACK MC <-- |3|4| n octets of data | DATA #3 |4|4| --> ACK MC <-- |3|5| ACK 6 Security Considerations The basic TFTP protocol has no security mechanism. This is why it has no rename, delete, or file overwrite capabilities. This document does not add any security to TFTP; however, the specified extensions do not add any additional security risks. 7 References [1] The TFTP Protocol (Revision 2) RFC 783 [2] TFTP Option Extension RFC 2347 [3] TFTP Blocksize Option RFC 2348 [4] Extensible Firmware Interface Specification PXE BaseCode Protocol http://www.intel.com/technology/efi/index.htm [5] Preboot eXecution Environment (PXE) Specification ftp://download.intel.com/labs/manage/wfm/download/pxespec.p df [6] TFTP Timeout Interval and Transfer Size Options RFC 2348 8 Author's Address Michael Johnston Intel Corporation MS. JF1-239 2111 NE 25th Ave. Hillsboro, OR 97124 M. Johnston draft-johnston-tftp-multicast-02.txt [Page 10] Internet Draft TFTP Multicast Option July, 2003 Phone: +1 503-264-9703 Email: michael.johnston@intel.com 9 Full Copyright Statement Copyright (C) The Internet Society (2002). 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 implementation 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, THE INTERNET ENGINEERING TASK FORCE, THE AUTHOR AND THE AUTHOR'S EMPLOYER DISCLAIM 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. M. Johnston draft-johnston-tftp-multicast-02.txt [Page 11]