From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2090.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc2090.txt (limited to 'doc/rfc/rfc2090.txt') diff --git a/doc/rfc/rfc2090.txt b/doc/rfc/rfc2090.txt new file mode 100644 index 0000000..dd2aeb7 --- /dev/null +++ b/doc/rfc/rfc2090.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group A. Emberson +Request for Comments: 2090 Lanworks Technologies Inc. +Category: Experimental February 1997 + + + TFTP Multicast Option + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. This memo does not specify an Internet standard of any + kind. Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Abstract + + The Trivial File Transfer Protocol [1] is a simple, lock-step, file + transfer protocol which allows a client to get or put a file onto a + remote host. + + This document describes a new TFTP option. This new option will allow + the multiple clients to receive the same file concurrently through + the use of Multicast packets. The TFTP Option Extension mechanism is + described in [2]. + + Often when similar computers are booting remotely they will each + download the same image file. By adding multicast into the TFTP + option set, two or more computers can download a file + concurrently, thus increasing network efficiency. + + This document assumes that the reader is familiar with the + terminology and notation of both [1] and [2]. + +Multicast Option Specification + + The TFTP Read Request packet is modified to include the multicast + option as follows: + + +--------+----~~----+---+--~~--+---+-----------+---+---+ + | opc=1 | filename | 0 | mode | 0 | multicast | 0 | 0 | + +--------+----~~----+---+--~~--+---+-----------+---+---+ + + opc + The opcode field contains a 1, for Read Requests, as defined + in [1]. + + + + + + +Emberson Experimental [Page 1] + +RFC 2090 TFTP Multicast Option February 1997 + + + filename + The name of the file to be read, as defined in [1]. This is a + NULL-terminated field. + + mode + The mode of the file transfer: "netascii", "octet", or + "mail", as defined in [1]. This is a NULL-terminated field. + + multicast + Request for multicast transmission of the file option, + "multicast" (case insensitive). This is a NULL-terminated + field. The value for this option request is a string of zero + length. + + If the server is willing to accept the multicast option, it + sends an Option Acknowledgment (OACK) to the client including + the multicast option, as defined in [2]. The OACK to the client + will specify the multicast address and flag to indicate whether + that client should send block acknowledgments (ACK). + + +-------+-----------+---+-------~~-------+---+ + | opc | multicast | 0 | addr, port, mc | 0 | + +-------+-----------+---+-------~~-------+---+ + + opc + The opcode field contains the number 6, for Option + Acknowledgment, as defined in [2]. + + multicast + Acknowledges the multicast option. This is a NULL-terminated + field. + + addr + The addr field contains the multicast IP address. This field + is terminated with a comma. + + port + The port field contains the destination port of the multicast + packets. The use of Registered Port number 1758 (tftp-mcast) + is recommended. This field is terminated with a comma. + + mc + This field will be either 0 or 1, to tell the client whether + it is the master client, that is, it is responsible for + sending ACKs to the server. This is NULL-terminated field. + + + + + + +Emberson Experimental [Page 2] + +RFC 2090 TFTP Multicast Option February 1997 + + +Data Transfer + + After the OACK is received by the client it will send an ACK for + packet zero, as in [2]. With the multicast option being accepted this + ACK will indicate to the server that the client wants the first + packet. In other words the ACKs may now be seen as a request for the + n+1th block of data. This enables each a client to request any block + within the file that it may be missing. + + To manage the data transfer the server will maintain a list of + clients. Typically the oldest client on the list, from here on + referred to as the Master Client, will be responsible for sending + ACKs. When the master client is finished, the server will send + another OACK to the next oldest client, telling it to start sending + ACKs. Upon receipt of this OACK the new master client will send an + ACK for the block immediately before the first block required to + complete its download. + + Any subsequent clients can start receiving blocks of a file during a + transfer and then request any missing blocks when that client becomes + the master client. When the current master client is finished, the + server will notify the next client with an OACK making it the new + master client. The new master client can start requesting missed + packets. Each client must terminate the transfer by sending an + acknowledgment of the last packet or by sending an error message to + server. This termination can occur even if the client is not the + master client. + + Any subsequent OACKs to a client may have an empty multicast address + and port fields, since this information will already be held by that + client. In the event a client fails to respond in a timely manner to + a OACK enabling it as the master client, the server shall select the + next oldest client to be the master client. The server shall + reattempt to send a OACK to the non- responding client when the new + master client is finished. The server may cease communication with a + client after a reasonable number of attempts. + + Each transfer will be given a multicast address for use to distribute + the data packets. Since there can be multiple servers on a given + network or a limited number of addresses available to a given server, + it is possible that their might be more than one transfer using a + multicast address. To ensure that a client only accepts the correct + packets, each transfer must use a unique port on the server. The + source IP address and port number will identify the data packets for + the transfer. Thus the server must send the unicast OACK packet to + the client using the same port as will be used for sending the + multicast data packets. + + + + +Emberson Experimental [Page 3] + +RFC 2090 TFTP Multicast Option February 1997 + + + At any point if a client, other than the master client, sends a ACK + to the server, the server will respond with another OACK with the mc + field holding a value of zero. If this client persists in sending + erroneous ACKs, the server may send an error packet to the client, + discontinuing the file transfer for that client. + + The server may also send unicast packets to a lone client to reduce + adverse effects on other machines. As it is possible that machines + may be forced to process many extraneous multicast packets when + attempting to receive a single multicast address. + +Example + + clients server message + ------------------------------------------------------------ + 1 C1 |1|afile|0|octet|0|multicast|0|0| -> RRQ + 2 C1 <- |6|multicast|224.100.100.100,1758,1| OACK + 3 C1 |4|0| -> ACK + 4 M <- |3|1|1| 512 octets of data| DATA + 5 C1 |4|1| -> ACK + 6 M <- |3|2|1| 512 octets of data| DATA + 7 C2 |1|afile|0|octet|0|multicast|0|0| -> RRQ + 8 C2 <- |6|multicast|224.100.100.100,1758,0| OACK + 9 C2 |4|0| -> ACK + 10 C1 |4|2| -> ACK + 11 M <- |3|3|1| 512 octets of data| DATA + 12 C3 |1|afile|0|octet|0|multicast|0|0| -> RRQ + 13 C3 <- |6|multicast|224.100.100.100,1758,0| OACK + 14 C1 |4|3| -> ACK + 15 C2 |4|0| -> ACK + 16 M (except C2) <- |3|4|1| 512 octets of data| DATA + 17 C1 |4|4| -> ACK + 18 M <- |3|5|1| 512 octets of data| DATA + 19 C1 |4|5| -> ACK + 20 M <- |3|6|1| 100 octets of data| DATA + 21 C1 |4|6| -> ACK + 22 C2 <- |6|multicast|,,1| OACK + 23 C2 |4|0| -> ACK + 24 M <- |3|1|1| 512 octets of data| DATA + 25 C2 |4|1| -> ACK + 26 M <- |3|2|1| 512 octets of data| DATA + 27 C2 |4|3| -> ACK + 28 M <- |3|4|1| 512 octets of data| DATA + 29 C2 |4|6| -> ACK + 30 C3 <- |6|multicast|,,1| OACK + 31 C3 |4|2| -> ACK + 32 M <- |3|3|1| 512 octets of data| DATA + 33 C3 |4|6| -> ACK + + + +Emberson Experimental [Page 4] + +RFC 2090 TFTP Multicast Option February 1997 + + + Comments: + 1 request from client 1 + 2 option acknowledgment + 3 acknowledgment for option acknowledgment, + or request for first block of data + 4 first data packet sent to the multicast address + 7 request from client 2 + 8 option acknowledgment to client 2, + send no acknowledgments + 9 OACK acknowledgment from client 2 + 15 OACK acknowledgment from client 3 + 16 client 2 fails to receive a packet + 21 client 1 acknowledges receipt of the last block, + telling the server it is done + 23 option acknowledgment to client 2, + now the master client + 25 client 2 acknowledging with request for first block + 27 client 2 acknowledges with request for missed block + 29 client 2 signals it is finished + 31 client 3 is master client and asks for missing blocks + 33 client 3 signals it is finished + +Conclusion + + With the use of the multicast and blocksize[3] options TFTP will be + capable of fast and efficient downloads of data. Using TFTP with the + multicast option will maintain backward compatibility for both + clients and servers. + +Security Considerations + + Security issues are not discussed in this memo. + +References + + [1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC + 1350, MIT, July 1992. + + [2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC + 1782, Xylogics, Inc., Hewlett Packard Co., March 1995. + + [3] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC + 1783, Xylogics, Inc., Hewlett Packard Co., March 1995. + + + + + + + + +Emberson Experimental [Page 5] + +RFC 2090 TFTP Multicast Option February 1997 + + +Author's Address + + A. Thomas Emberson + Lanworks Technologies, Inc. + 2425 Skymark Avenue + Mississauga, Ontario + Canada L4W 4Y6 + + + Phone: (905) 238-5528 + EMail: tom@lanworks.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Emberson Experimental [Page 6] + -- cgit v1.2.3