idnits 2.17.1 draft-emberson-tftp-multicast-opt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-emberson-tftp-multicast-option-00', but the file name used is 'draft-emberson-tftp-multicast-opt-00' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 25 has weird spacing: '...ctories on ...' == Line 42 has weird spacing: '... option set, ...' == Line 50 has weird spacing: '...Request packe...' == Line 70 has weird spacing: '...Request for ...' == Line 86 has weird spacing: '... The opcod...' == (2 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (August 1996) is 10114 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1782 (ref. '2') (Obsoleted by RFC 2347) ** Obsolete normative reference: RFC 1783 (ref. '3') (Obsoleted by RFC 2348) Summary: 12 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft 2 A. T. Emberson 3 Lanworks Technologies Inc. 4 Document: draft-emberson-tftp-multicast-option-00.txt 5 August 1996 6 Expire in six months 8 TFTP Multicast Option 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check 24 the ``1id-abstracts.txt'' listing contained in the Internet- 25 Drafts Shadow Directories on ftp.is.co.za (Africa), 26 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 27 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 29 Abstract 31 The Trivial File Transfer Protocol [1] is a simple, lock-step, 32 file transfer protocol which allows a client to get or put a 33 file onto a remote host. 35 This document describes a new TFTP option. This new option will 36 allow the multiple clients to receive the same file concurrently 37 through the use of Multicast packets. The TFTP Option Extension 38 mechanism is described in [2]. 40 Often when similar computers are booting remotely they will each 41 download the same image file. By adding multicast into the TFTP 42 option set, two or more computers can download a file 43 concurrently, thus increasing network efficiency. 45 This document assumes that the reader is familiar with the 46 terminology and notation of both [1] and [2]. 48 Multicast Option Specification 50 The TFTP Read Request packet is modified to include the 51 multicast option as follows: 53 +--------+----~~----+---+--~~--+---+-----------+---+---+ 54 | opc=1 | filename | 0 | mode | 0 | multicast | 0 | 0 | 55 +--------+----~~----+---+--~~--+---+-----------+---+---+ 57 opc 58 The opcode field contains a 1, for Read Requests, as defined 59 in [1]. 61 filename 62 The name of the file to be read, as defined in [1]. This is a 63 NULL-terminated field. 65 mode 66 The mode of the file transfer: "netascii", "octet", or 67 "mail", as defined in [1]. This is a NULL-terminated field. 69 multicast 70 Request for multicast transmission of the file option, 71 "multicast" (case insensitive). This is a NULL-terminated 72 field. The value for this option request is a string of zero 73 length. 75 If the server is willing to accept the multicast option, it 76 sends an Option Acknowledgment (OACK) to the client including 77 the multicast option, as defined in [2]. The OACK to the client 78 will specify the multicast address and flag to indicate whether 79 that client should send block acknowledgments (ACK). 81 +-------+-----------+---+-------~~-------+---+ 82 | opc | multicast | 0 | addr, port, mc | 0 | 83 +-------+-----------+---+-------~~-------+---+ 85 opc 86 The opcode field contains the number 6, for Option 87 Acknowledgment, as defined in [2]. 89 multicast 90 Acknowledges the multicast option. This is a NULL-terminated 91 field. 93 addr 94 The addr field contains the multicast IP address. This field 95 is terminated with a comma. 97 port 98 The port field contains the destination port of the multicast 99 packets. This field is terminated with a comma. 101 mc 102 This field will be either 0 or 1, to tell the client whether 103 it is the master client, that is, it is responsible for 104 sending ACKs to the server. This is NULL-terminated field. 106 Data Transfer 108 After the OACK is received by the client it will send an ACK for 109 packet zero, as in [2]. With the multicast option being accepted 110 this ACK will indicate to the server that the client wants the 111 first packet. In other words the ACKs may now be seen as a 112 request for the n+1th block of data. This enables each a client 113 to request any block within the file that it may be missing. 115 To manage the data transfer the server will maintain a list of 116 clients. Typically the oldest client on the list, from here on 117 referred to as the Master Client, will be responsible for 118 sending ACKs. When the master client is finished, the server 119 will send another OACK to the next oldest client, telling it to 120 start sending ACKs. Upon receipt of this OACK the new master 121 client will send an ACK for the block immediately before the 122 first block required to complete its download. 124 Any subsequent clients can start receiving blocks of a file 125 during a transfer and then request any missing blocks when that 126 client becomes the master client. When the current master client 127 is finished, the server will notify the next client with an OACK 128 making it the new master client. The new master client can start 129 requesting missed packets. Each client must terminate the 130 transfer by sending an acknowledgment of the last packet or by 131 sending an error message to server. This termination can occur 132 even if the client is not the master client. 134 Any subsequent OACKs to a client may have an empty multicast 135 address and port fields, since this information will already be 136 held by that client. In the event a client fails to respond in a 137 timely manner to a OACK enabling it as the master client, the 138 server shall select the next oldest client to be the master 139 client. The server shall reattempt to send a OACK to the non- 140 responding client when the new master client is finished. The 141 server may cease communication with a client after a reasonable 142 number of attempts. 144 Each transfer will be given a multicast address for use to 145 distribute the data packets. Since there can be multiple servers 146 on a given network or a limited number of addresses available to 147 a given server, it is possible that their might be more than one 148 transfer using a multicast address. To ensure that a client only 149 accepts the correct packets, each transfer must use a unique 150 port on the server. The source IP address and port number will 151 identify the data packets for the transfer. Thus the server must 152 send the unicast OACK packet to the client using the same port 153 as will be used for sending the multicast data packets. 155 At any point if a client, other than the master client, sends a 156 ACK to the server, the server will respond with another OACK 157 with the mc field holding a value of zero. If this client 158 persists in sending erroneous ACKs, the server may send an error 159 packet to the client, discontinuing the file transfer for that 160 client. 162 The server may also send unicast packets to a lone client to 163 reduce adverse effects on other machines. As it is possible that 164 machines may be forced to process many extraneous multicast 165 packets when attempting to receive a single multicast address. 167 Example 169 clients server message 170 ------------------------------------------------------------ 171 1 C1 |1|afile|0|octet|0|multicast|0|0| -> RRQ 172 2 C1 <- |6|multicast|224.100.100.100,1010,1| OACK 173 3 C1 |4|0| -> ACK 174 4 C1 <- |3|1|1| 512 octets of data| DATA 175 5 C1 |4|1| -> ACK 176 6 C1 <- |3|2|1| 512 octets of data| DATA 177 7 C2 |1|afile|0|octet|0|multicast|0|0| -> RRQ 178 8 C2 <- |6|multicast|224.100.100.100,1010,0| OACK 179 9 C2 |4|0| -> ACK 180 10 C1 |4|2| -> ACK 181 11 M <- |3|3|1| 512 octets of data| DATA 182 12 C3 |1|afile|0|octet|0|multicast|0|0| -> RRQ 183 13 C3 <- |6|multicast|224.100.100.100,1010,0| OACK 184 14 C1 |4|3| -> ACK 185 15 C2 |4|0| -> ACK 186 16 M (except C2) <- |3|4|1| 512 octets of data| DATA 187 17 C1 |4|4| -> ACK 188 18 M <- |3|5|1| 512 octets of data| DATA 189 19 C1 |4|5| -> ACK 190 20 M <- |3|6|1| 100 octets of data| DATA 191 21 C1 |4|6| -> ACK 192 22 C2 <- |6|multicast|,,1| OACK 193 23 C2 |4|0| -> ACK 194 24 M <- |3|1|1| 512 octets of data| DATA 195 25 C2 |4|1| -> ACK 196 26 M <- |3|2|1| 512 octets of data| DATA 197 27 C2 |4|3| -> ACK 198 28 M <- |3|4|1| 512 octets of data| DATA 199 29 C2 |4|6| -> ACK 200 30 C3 <- |6|multicast|,,1| OACK 201 31 C3 |4|2| -> ACK 202 32 C3 <- |3|3|1| 512 octets of data| DATA 203 33 C3 |4|6| -> ACK 204 Comments: 205 1 request from client 1 206 2 option acknowledgment 207 3 acknowledgment for option acknowledgment, 208 or request for first block of data 209 4 first data packet sent to the multicast address 210 7 request from client 2 211 8 option acknowledgment to client 2, 212 send no acknowledgments 213 9 OACK acknowledgment from client 2 214 15 OACK acknowledgment from client 3 215 16 client 2 fails to receive a packet 216 21 client 1 acknowledges receipt of the last block, 217 telling the server it is done 218 23 option acknowledgment to client 2, 219 now the master client 220 25 client 2 acknowledging with request for first block 221 27 client 2 acknowledges with request for missed block 222 29 client 2 signals it is finished 223 31 client 3 is master client and asks for missing blocks 224 33 client 3 signals it is finished 226 Conclusion 228 With the use of the multicast and blocksize[3] options TFTP will 229 be capable of fast and efficient downloads of data. Using TFTP 230 with the multicast option will maintain backward compatibility 231 for both clients and servers. 233 Security Considerations 235 Security issues are not discussed in this memo. 237 References 239 [1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 240 1350, 241 MIT, July 1992. 243 [2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC 244 1782, 245 Xylogics, Inc., Hewlett Packard Co., March 1995. 247 [3] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 248 1783, 249 Xylogics, Inc., Hewlett Packard Co., March 1995. 251 Authors Address 253 A. Thomas Emberson 254 Lanworks Technologies, Inc. 255 2425 Skymark Avenue 256 Mississauga, Ontario 257 Canada L4W 4Y6 259 Phone: (905) 238-5528 260 EMail: tom@lanworks.com