TFTP Multicast Option
RFC 2090

Document Type RFC - Experimental (February 1997; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 2090 (Experimental)
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text