home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 2000s / rfc2090.txt < prev    next >
Text File  |  1997-02-02  |  12KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       A. Emberson
  8. Request for Comments: 2090                   Lanworks Technologies Inc.
  9. Category: Experimental                                    February 1997
  10.  
  11.  
  12.                          TFTP Multicast Option
  13.  
  14. Status of this Memo
  15.  
  16.    This memo defines an Experimental Protocol for the Internet
  17.    community.  This memo does not specify an Internet standard of any
  18.    kind.  Discussion and suggestions for improvement are requested.
  19.    Distribution of this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    The Trivial File Transfer Protocol [1] is a simple, lock-step, file
  24.    transfer protocol which allows a client to get or put a file onto a
  25.    remote host.
  26.  
  27.    This document describes a new TFTP option. This new option will allow
  28.    the multiple clients to receive the same file concurrently through
  29.    the use of Multicast packets. The TFTP Option Extension mechanism is
  30.    described in [2].
  31.  
  32.    Often when similar computers are booting remotely they will each
  33.    download the same image file. By adding multicast into the TFTP
  34.    option  set,  two  or  more  computers  can  download  a  file
  35.    concurrently, thus increasing network efficiency.
  36.  
  37.    This document assumes that the reader is familiar with the
  38.    terminology and notation of both [1] and [2].
  39.  
  40. Multicast Option Specification
  41.  
  42.    The TFTP Read Request packet is modified to include the multicast
  43.    option as follows:
  44.  
  45.       +--------+----~~----+---+--~~--+---+-----------+---+---+
  46.       |  opc=1 | filename | 0 | mode | 0 | multicast | 0 | 0 |
  47.       +--------+----~~----+---+--~~--+---+-----------+---+---+
  48.  
  49.    opc
  50.       The opcode field contains a 1, for Read Requests, as defined
  51.       in [1].
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Emberson                      Experimental                      [Page 1]
  59.  
  60. RFC 2090                 TFTP Multicast Option             February 1997
  61.  
  62.  
  63.    filename
  64.       The name of the file to be read, as defined in [1]. This is a
  65.       NULL-terminated field.
  66.  
  67.    mode
  68.       The mode of the file transfer: "netascii", "octet", or
  69.       "mail", as defined in [1]. This is a NULL-terminated field.
  70.  
  71.    multicast
  72.       Request  for  multicast  transmission  of  the  file  option,
  73.       "multicast" (case insensitive). This is a NULL-terminated
  74.       field. The value for this option request is a string of zero
  75.       length.
  76.  
  77.    If the server is willing to accept the multicast option, it
  78.    sends an Option Acknowledgment (OACK) to the client including
  79.    the multicast option, as defined in [2]. The OACK to the client
  80.    will specify the multicast address and flag to indicate whether
  81.    that client should send block acknowledgments (ACK).
  82.  
  83.      +-------+-----------+---+-------~~-------+---+
  84.      |  opc  | multicast | 0 | addr, port, mc | 0 |
  85.      +-------+-----------+---+-------~~-------+---+
  86.  
  87.    opc
  88.       The  opcode  field  contains  the  number  6,  for  Option
  89.       Acknowledgment, as defined in [2].
  90.  
  91.    multicast
  92.       Acknowledges the multicast option. This is a NULL-terminated
  93.       field.
  94.  
  95.    addr
  96.       The addr field contains the multicast IP address. This field
  97.       is terminated with a comma.
  98.  
  99.    port
  100.       The port field contains the destination port of the multicast
  101.       packets. The use of Registered Port number 1758 (tftp-mcast)
  102.       is recommended. This field is terminated with a comma.
  103.  
  104.    mc
  105.       This field will be either 0 or 1, to tell the client whether
  106.       it is the master client, that is, it is responsible for
  107.       sending ACKs to the server. This is NULL-terminated field.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Emberson                      Experimental                      [Page 2]
  115.  
  116. RFC 2090                 TFTP Multicast Option             February 1997
  117.  
  118.  
  119. Data Transfer
  120.  
  121.    After the OACK is received by the client it will send an ACK for
  122.    packet zero, as in [2]. With the multicast option being accepted this
  123.    ACK will indicate to the server that the client wants the first
  124.    packet. In other words the ACKs may now be seen as a request for the
  125.    n+1th block of data. This enables each a client to request any block
  126.    within the file that it may be missing.
  127.  
  128.    To manage the data transfer the server will maintain a list of
  129.    clients. Typically the oldest client on the list, from here on
  130.    referred to as the Master Client, will be responsible for sending
  131.    ACKs. When the master client is finished, the server will send
  132.    another OACK to the next oldest client, telling it to start sending
  133.    ACKs. Upon receipt of this OACK the new master client will send an
  134.    ACK for the block immediately before the first block required to
  135.    complete its download.
  136.  
  137.    Any subsequent clients can start receiving blocks of a file during a
  138.    transfer and then request any missing blocks when that client becomes
  139.    the master client. When the current master client is finished, the
  140.    server will notify the next client with an OACK making it the new
  141.    master client. The new master client can start requesting  missed
  142.    packets.  Each  client  must  terminate  the transfer by sending an
  143.    acknowledgment of the last packet or by sending an error message to
  144.    server. This termination can occur even if the client is not the
  145.    master client.
  146.  
  147.    Any subsequent OACKs to a client may have an empty multicast address
  148.    and port fields, since this information will already be held by that
  149.    client. In the event a client fails to respond in a timely manner to
  150.    a OACK enabling it as the master client, the server shall select the
  151.    next oldest client to be the master client. The server shall
  152.    reattempt to send a OACK to the non- responding client when the new
  153.    master client is finished. The server may cease communication with a
  154.    client after a reasonable number of attempts.
  155.  
  156.    Each transfer will be given a multicast address for use to distribute
  157.    the data packets. Since there can be multiple servers on a given
  158.    network or a limited number of addresses available to a given server,
  159.    it is possible that their might be more than one transfer using a
  160.    multicast address. To ensure that a client only accepts the correct
  161.    packets, each transfer must use a unique port on the server. The
  162.    source IP address and port number will identify the data packets for
  163.    the transfer. Thus the server must send the unicast OACK packet to
  164.    the client using the same port as will be used for sending the
  165.    multicast data packets.
  166.  
  167.  
  168.  
  169.  
  170. Emberson                      Experimental                      [Page 3]
  171.  
  172. RFC 2090                 TFTP Multicast Option             February 1997
  173.  
  174.  
  175.    At any point if a client, other than the master client, sends a ACK
  176.    to the server, the server will respond with another OACK with the mc
  177.    field holding a value of zero. If this client persists in sending
  178.    erroneous ACKs, the server may send an error packet to the client,
  179.    discontinuing the file transfer for that client.
  180.  
  181.    The server may also send unicast packets to a lone client to reduce
  182.    adverse effects on other machines. As it is possible that machines
  183.    may be forced to process many extraneous multicast packets when
  184.    attempting to receive a single multicast address.
  185.  
  186. Example
  187.  
  188.            clients                                      server  message
  189.            ------------------------------------------------------------
  190.     1  C1  |1|afile|0|octet|0|multicast|0|0| ->                  RRQ
  191.     2                C1 <- |6|multicast|224.100.100.100,1758,1|  OACK
  192.     3  C1  |4|0| ->                                              ACK
  193.     4                          M <- |3|1|1| 512 octets of data|  DATA
  194.     5  C1  |4|1| ->                                              ACK
  195.     6                          M <- |3|2|1| 512 octets of data|  DATA
  196.     7  C2  |1|afile|0|octet|0|multicast|0|0| ->                  RRQ
  197.     8                C2 <- |6|multicast|224.100.100.100,1758,0|  OACK
  198.     9  C2  |4|0| ->                                              ACK
  199.    10  C1  |4|2| ->                                              ACK
  200.    11                          M <- |3|3|1| 512 octets of data|  DATA
  201.    12  C3  |1|afile|0|octet|0|multicast|0|0| ->                  RRQ
  202.    13                C3 <- |6|multicast|224.100.100.100,1758,0|  OACK
  203.    14  C1  |4|3| ->                                              ACK
  204.    15  C2  |4|0| ->                                              ACK
  205.    16              M (except C2) <- |3|4|1| 512 octets of data|  DATA
  206.    17  C1  |4|4| ->                                              ACK
  207.    18                          M <- |3|5|1| 512 octets of data|  DATA
  208.    19  C1  |4|5| ->                                              ACK
  209.    20                          M <- |3|6|1| 100 octets of data|  DATA
  210.    21  C1  |4|6| ->                                              ACK
  211.    22                                   C2 <- |6|multicast|,,1|  OACK
  212.    23  C2  |4|0| ->                                              ACK
  213.    24                          M <- |3|1|1| 512 octets of data|  DATA
  214.    25  C2  |4|1| ->                                              ACK
  215.    26                          M <- |3|2|1| 512 octets of data|  DATA
  216.    27  C2  |4|3| ->                                              ACK
  217.    28                          M <- |3|4|1| 512 octets of data|  DATA
  218.    29  C2  |4|6| ->                                              ACK
  219.    30                                   C3 <- |6|multicast|,,1|  OACK
  220.    31  C3  |4|2| ->                                              ACK
  221.    32                          M <- |3|3|1| 512 octets of data|  DATA
  222.    33  C3  |4|6| ->                                              ACK
  223.  
  224.  
  225.  
  226. Emberson                      Experimental                      [Page 4]
  227.  
  228. RFC 2090                 TFTP Multicast Option             February 1997
  229.  
  230.  
  231.       Comments:
  232.          1  request from client 1
  233.          2  option acknowledgment
  234.          3  acknowledgment for option acknowledgment,
  235.             or request for first block of data
  236.          4  first data packet sent to the multicast address
  237.          7  request from client 2
  238.          8  option acknowledgment to client 2,
  239.             send no acknowledgments
  240.          9  OACK acknowledgment from client 2
  241.          15 OACK acknowledgment from client 3
  242.          16 client 2 fails to receive a packet
  243.          21 client 1 acknowledges receipt of the last block,
  244.             telling the server it is done
  245.          23 option acknowledgment to client 2,
  246.             now the master client
  247.          25 client 2 acknowledging with request for first block
  248.          27 client 2 acknowledges with request for missed block
  249.          29 client 2 signals it is finished
  250.          31 client 3 is master client and asks for missing blocks
  251.          33 client 3 signals it is finished
  252.  
  253. Conclusion
  254.  
  255.    With the use of the multicast and blocksize[3] options TFTP will be
  256.    capable of fast and efficient downloads of data. Using TFTP with the
  257.    multicast option will maintain backward compatibility for both
  258.    clients and servers.
  259.  
  260. Security Considerations
  261.  
  262.    Security issues are not discussed in this memo.
  263.  
  264. References
  265.  
  266.    [1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC
  267.        1350, MIT, July 1992.
  268.  
  269.    [2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC
  270.        1782, Xylogics, Inc., Hewlett Packard Co., March 1995.
  271.  
  272.    [3] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC
  273.        1783, Xylogics, Inc., Hewlett Packard Co., March 1995.
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Emberson                      Experimental                      [Page 5]
  283.  
  284. RFC 2090                 TFTP Multicast Option             February 1997
  285.  
  286.  
  287. Author's Address
  288.  
  289.    A. Thomas Emberson
  290.    Lanworks Technologies, Inc.
  291.    2425 Skymark Avenue
  292.    Mississauga, Ontario
  293.    Canada L4W 4Y6
  294.  
  295.  
  296.    Phone: (905) 238-5528
  297.    EMail: tom@lanworks.com
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Emberson                      Experimental                      [Page 6]
  339.  
  340.