idnits 2.17.1 draft-rfced-exp-yung-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 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. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 4 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2090, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 177 has weird spacing: '... server messa...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1998) is 9505 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1782 (ref. '2') (Obsoleted by RFC 2347) ** Obsolete normative reference: RFC 1783 (ref. '3') (Obsoleted by RFC 2348) Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT EXPIRES NOV 1998 INTERNET DRAFT 2 Network Working Group W. C. Yung 3 INTERNET DRAFT Lanworks Technologies Inc. 4 Obsoletes: RFC 2090 April 1998 5 Category: Experimental 7 TFTP Multicast Option 8 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 view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 Distribution of this document is unlimited. 32 Acknowledgements 34 The protocol, as defined in [4], was originally designed by A. Thomas 35 Emberson. The current revision of the document includes modifications 36 of the interaction between a TFTP server and clients after the first 37 data transfer. The re-request scheme was also redesigned to give a high 38 priority to the slower client on a network. 40 Abstract 42 The Trivial File Transfer Protocol [1] is a simple, lock-step, file 43 transfer protocol which allows a client to get or put a file onto a 44 remote host. 46 This document describes a new TFTP option. This new option will allow 47 the multiple client to receive the same file concurrently through the 48 use of Multicast packets. The TFTP Option Extension mechanism is 49 described in [2]. 51 Often when similar computers are booting remotely they will each 52 download the same image file. By adding multicast into the TFTP option 53 set, two or more computers can download a file concurrently, thus 54 increasing network efficiency. 56 This document assumes that the reader is familiar with the terminology 57 and notation of both [1] and [2]. 59 Multicast Option Specification 61 The TFTP Read Request packet is modified to include the multicast option 62 as follows: 64 +--------+----~~----+---+--~~--+---+-----------+---+---+ 65 | opc=1 | filename | 0 | mode | 0 | multicast | 0 | 0 | 66 +--------+----~~----+---+--~~--+---+-----------+---+---+ 68 opc 69 The opcode field contains a 1, for Read Requests, as defined in [1]. 71 filename 72 The name of the file to be read, as defined in [1]. This is a 73 NULL-terminated field. 75 mode 76 The mode of the file transfer: "netascii", "octet", or "mail", as 77 defined in [1]. This is a NULL-terminated field. 79 multicast 80 Request for multicast transmission of the file option, "multicast" 81 (case insensitive). This is a NULL-terminated field. The value for 82 this option request is a string of zero length. 84 If the server is willing to accept the multicast option, it sends 85 an Option Acknowledgment (OACK) to the client including the 86 multicast option, as defined in [2]. The OACK to the client will 87 specify the multicast address and flag to indicate whether that 88 client should send block acknowledgments (ACK). The exchange of the 89 multicast information will by default uses registered port 1758 for 90 server, and registered port 1759 for client. 92 +--------+-----------+---+-------~~-------+---+ 93 | opc=6 | multicast | 0 | addr, port, mc | 0 | 94 +--------+-----------+---+-------~~-------+---+ 96 opc 97 The opcode field contains the number 6, for Option Acknowledgment, 98 as defined in [2]. 100 multicast 101 Acknowledges the multicast option. This is a NULL-terminated field. 103 addr 104 The addr field contains the multicast IP address. This field is 105 terminated with a comma. 107 port 108 The port field contains the destination port of the multicast 109 packets. This field is terminated with a comma. 111 mc 112 This field will be either 0 or 1, to tell the client whether it is 113 the master client, that is, it is responsible for sending ACKs to 114 the server. This is NULL-terminated field. 116 Data Transfer 118 After the OACK is received by a client, it will send an ACK for packet 119 zero to the assigned multicast IP address if the mc field is set to 1. 120 With the mc field holding a value of 1, the OACK indicates to the client 121 that it is the first client requesting this file, and it is the master 122 client as well. Also with the multicast option being accepted, the ACK 123 indicates to the server that the client wants the first packet. 125 For any subsequent clients requesting for the same file, the server will 126 respond with an OACK which is identical to the one for the master client, 127 except for the mc field which will hold a value of 0 instead of 1. Upon 128 finish exchanging the multicast information, clients can begin to receive 129 data packets immediately without sending any ACKs for the following 130 received data packets. 132 To manage the data transfer, the server will maintain a list of clients 133 requesting for the same file. Server uses the list only for switching 134 master client in case the current master client fails to acknowledge 135 the received packets. Typically when the server finishes one complete 136 file transfer, it will wait for a random period for any new request of 137 the same file before it leave the assigned multicast IP address. It is 138 the client's responsibility to re-request a new transmission if there 139 are still some packets missing. The server shall not initiate any new 140 data transfer. 142 If there are clients still missing some packets after one data transfer, 143 they will all delay for a short period before the next RRQs are sent. 144 The delay is a decreasing function of the number of missing packets and 145 increasing function of the number of packets received. This design is 146 laid out in such way that the slower client should be always given a 147 greater opportunity to be the acknowledging client. In other words, 148 the more packets that a client has received, the faster the client 149 is likely to be, and vice versa. 151 In the event of the master client failing to acknowledge a received 152 packet after several attempts, the server will take the next client, if 153 there is one, from the list, and send an OACK with the mc field holding 154 a value of 1, the multicast IP address and port fields blank. The server 155 assumes the client has already held the information about multicast 156 address and port number of the data transfer. 158 Each different file transfer will be given a different multicast address 159 for use to distribute the data packets. Since there can be multiple 160 servers on a given network or a limited number of addresses available to 161 a given server, it is possible that their might be more than one 162 transfer using a multicast address. To ensure that a client only accepts 163 the correct packets, each transfer must use a unique port on the server. 164 The source IP address and port number will identify the data packets for 165 the transfer. Thus the server must send the unicast OACK packet to the 166 client first, and the server will start sending data packets to the 167 client using the assigned port once an ACK is received from a client. 169 At any point during a data transfer, other than the master client, sends 170 an ACK to the server, the server will respond with another OACK with the 171 mc field holding a value of 0. If this client persists in sending 172 erroneous ACKs, the server may send an error packet to the client, 173 discontinuing the file transfer for that client. 175 Example 177 clients server message 178 ---------------------------------------------------------------- 179 1 C1 |1|afile|0|octet|0|multicast|0|0| -> RRQ 180 2 C1 <- |6|multicast|244.0.0.2,6901,1| OACK 181 3 C1 |4|0| -> M ACK 182 4 M <- |3|1|512 octets of data| DATA 183 5 C1 |4|1| -> M ACK 184 6 M <- |3|2|512 octets of data| DATA 185 7 C2 |1|afile|0|octet|0|multicast|0|0| -> RRQ 186 8 C2 <- |6|multicast|244.0.0.2,6901,0| OACK 187 9 C1 |4|2| -> M ACK 188 10 M <- |3|3|512 octets of data| DATA 189 11 C1 |4|3| -> M ACK 190 12 C3 |1|afile|0|octet|0|multicast|0|0| -> RRQ 191 13 C3 <- |6|multicast|244.0.0.2,6901,0| OACK 192 14 M <- |3|4|512 octets of data| DATA 194 15 C1 |4|4| -> M ACK 195 16 M <- |3|5|512 octets of data| DATA 196 17 C1 |4|5| -> M ACK 197 18 M <- |3|6|512 octets of data| DATA 198 19 M <- |3|6|512 octets of data| DATA 199 20 M <- |3|6|512 octets of data| DATA 200 21 C2 <- |6|multicast|,,1| OACK 201 22 C2 |4|6| -> M ACK 202 23 M <- |3|7|512 octets of data| DATA 203 24 C2 |4|7| -> M ACK 204 25 M <- |3|8|100 octets of data| DATA 205 26 C2 |4|8| -> M ACK 206 27 C3 |1|afile|0|octet|0|multicast|0|0| -> RRQ 207 28 C3 <- |6|multicast|244.0.0.2,6901,1| OACK 208 29 C3 |4|0| -> M ACK 209 30 C2 |1|afile|0|octet|0|multicast|0|0| -> RRQ 210 31 C2 <- |6|multicast|244.0.0.2,6901,0| OACK 211 32 M <- |3|1|512 octets of data| DATA 212 33 C3 |4|1| -> M ACK 213 34 M <- |3|2|512 octets of data| DATA 214 35 C3 |4|2| -> M ACK 215 36 M <- |3|3|512 octets of data| DATA 216 37 C3 |4|3| -> M ACK 217 38 M <- |3|4|512 octets of data| DATA 218 39 C3 |4|4| -> M ACK 219 40 M <- |3|5|512 octets of data| DATA 220 41 C3 |4|5| -> M ACK 221 42 M <- |3|6|512 octets of data| DATA 222 43 C3 |4|6| -> M ACK 223 44 M <- |3|7|512 octets of data| DATA 224 45 C3 |4|7| -> M ACK 225 46 M <- |3|8|100 octets of data| DATA 226 47 C3 |4|8| -> M ACK 228 Comments: 229 1 request from client 1 230 2 option acknowledgment to client 1 with mc field holding a value of 1 231 3 acknowledgment for option acknowledgment, or request for first block 232 4 first data packet sent to the multicast address 233 7 request from client 2 234 8 option acknowledgment to client 2 with mc field holding a value of 0 235 9 ACK acknowledgment of block # 2 from client 1 to the multicast address 236 12 request from client 3 238 13 option acknowledgment to client 2 with mc field holding a value of 0 239 18, 19, 20 server attempts 3 times if client 1 fails to acknowledge 240 21 server switch master client from client 1 to client 2 241 22 client 2 assumes the job to respond to the server 242 27, 30 client 3 re-request a file transfer after finding some packets 243 still missing from the first data transfer. client 3 misses more packets 244 than client 2, therefore client 3 is the master client for the next data 245 transfer 246 47 client 3 signals it received the last data packet of the transfer 248 Conclusion 250 With the use of the multicast and blocksize [3] options, TFTP will be 251 capable of fast and efficient downloading data. Using TFTP with the 252 multicast option will maintain backward compatibility for both client 253 and servers. 255 Security Considerations 257 Security issues are not discussed in this memo. 259 References 261 [1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, 262 MIT, July 1992. 264 [2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC 1782, 265 Xylogics, Inc., Hewlett Packard Co., March 1995. 267 [3] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 1783, 268 Xylogics, Inc., Hewlett Packard Co., March 1995. 270 [4] A. Thomas Emberson, "TFTP Multicast Option", RFC 2090, 271 Lanworks Technologies, Inc. February 1997. 273 Author's Address 275 Weng-Chin (Winson) Yung 276 Lanworks Technologies CO. 277 a subsidiary of 3Com Corporation 278 2425 Skymark Avenue 279 Mississagua, Ontario 280 Canada L4W 4Y6 282 Phone: (905) 238-5528 283 EMail: winson_yung@ne.3com.com 285 Full Copyright Statement 287 Copyright (C) The Internet Society (1997). All Rights Reserved. 289 This document and translations of it may be copied and furnished to 290 others, and derivative works that comment on or otherwise explain it 291 or assist in its implmentation may be prepared, copied, published and 292 distributed, in whole or in part, without restriction of any kind, 293 provided that the above copyright notice and this paragraph are 294 included on all such copies and derivative works. However, this 295 document itself may not be modified in any way, such as by removing 296 the copyright notice or references to the Internet Society or other 297 Internet organizations, except as needed for the purpose of 298 developing Internet standards in which case the procedures for 299 copyrights defined in the Internet Standards process must be 300 followed, or as required to translate it into languages other than 301 English. 303 The limited permissions granted above are perpetual and will not be 304 revoked by the Internet Society or its successors or assigns. 306 This document and the information contained herein is provided on an 307 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 308 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 309 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 310 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 311 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 313 INTERNET DRAFT EXPIRES NOV 1998 INTERNET DRAFT