doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

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]
+