Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-adm!ron
From: ron@brl-adm.ARPA (Ron Natalie <ron>)
Newsgroups: mod.sources.doc
Subject: rfc783 (2 of 2)
Message-ID: <694@brl-adm.ARPA>
Date: Tue, 13-May-86 08:52:58 EDT
Article-I.D.: brl-adm.694
Posted: Tue May 13 08:52:58 1986
Date-Received: Sat, 24-May-86 21:48:17 EDT
Distribution: net
Organization: Ballistic Research Lab
Lines: 285
Approved: RON@BRL.ARPA


                                             11


specification.



  It  is  also  possible  to define other modes for cooperating pairs of

hosts, although this must be done with care.  There  is  no  requirement

that  any  other  hosts  implement these.  There is no central authority

that will define these modes or assign them names.

                        Figure 5-2: DATA packet




                   2 bytes     2 bytes      n bytes
                   ----------------------------------
                  | Opcode |   Block #  |   Data     |
                   ----------------------------------



  Data is actually transferred in DATA packets depicted in  Figure  5-2.

DATA packets (opcode = 3) have a block number and data field.  The block

numbers  on data packets begin with one and increase by one for each new

block of data.  This restriction allows the  program  to  use  a  single

number  to  discriminate  between  new packets and duplicates.  The data

field is from zero to 512 bytes long.  If it  is  512  bytes  long,  the

block  is  not  the  last block of data; if it is from zero to 511 bytes

long, it signals the end of the transfer.  (See the  section  on  Normal

Termination for details.)



  All  packets  other  than  those used for termination are acknowledged

individually unless a timeout occurs.   Sending  a  DATA  packet  is  an

acknowledgment  for the ACK packet of the previous DATA packet.  The WRQ

and DATA packets are acknowledged by ACK or ERROR packets, while RRQ and
                                             12


                         Figure 5-3: ACK packet




                         2 bytes     2 bytes
                         ---------------------
                        | Opcode |   Block #  |
                         ---------------------


ACK  packets  are  acknowledged  by  DATA  or ERROR packets.  Figure 5-3

depicts an ACK packet; the opcode is 4.  The  block  number  in  an  ACK

echoes the block number of the DATA packet being acknowledged.  A WRQ is

acknowledged with an ACK packet having a block number of zero.

                        Figure 5-4: ERROR packet




               2 bytes     2 bytes      string    1 byte
               -----------------------------------------
              | Opcode |  ErrorCode |   ErrMsg   |   0  |
               -----------------------------------------



  An  ERROR packet (opcode 5) takes the form depicted in Figure 5-4.  An

ERROR packet can be the acknowledgment of any other type of packet.  The

error code is an integer indicating the nature of the error.  A table of

values and meanings is given in the appendix.  (Note that several  error

codes  have  been  added  to  this version of this document.)  The error

message is intended for human consumption, and should  be  in  netascii.

Like all other strings, it is terminated with a zero byte.
                                             13


6. Normal Termination

  The end of a transfer is marked by a DATA packet that contains between

0  and  511  bytes of data (i.e. Datagram length < 516).  This packet is

acknowledged by an ACK packet like all other DATA  packets.    The  host

acknowledging  the  final  DATA  packet  may  terminate  its side of the

connection on sending the final ACK.  On the  other  hand,  dallying  is

encouraged.    This  means that the host sending the final ACK will wait

for a while before terminating in order to retransmit the final  ACK  if

it has been lost.  The acknowledger will know that the ACK has been lost

if  it  receives the final DATA packet again.  The host sending the last

DATA must retransmit it until the packet is acknowledged or the  sending

host  times  out.    If  the  response  is  an ACK, the transmission was

completed successfully.  If the sender of the data times out and is  not

prepared  to  retransmit  any  more,  the  transfer  may still have been

completed successfully, after which the acknowledger or network may have

experienced a problem.  It is  also  possible  in  this  case  that  the

transfer was unsuccessful.  In any case, the connection has been closed.



7. Premature Termination

  If  a  request  can  not  be  granted, or some error occurs during the

transfer, then an ERROR packet (opcode 5) is  sent.    This  is  only  a

courtesy  since  it will not be retransmitted or acknowledged, so it may

never be received.  Timeouts must also be used to detect errors.
                                             14


I. Appendix


Order of Headers


                                               2 bytes
 ----------------------------------------------------------
|  Local Medium  |  Internet  |  Datagram  |  TFTP Opcode  |
 ----------------------------------------------------------


TFTP Formats


Type   Op #     Format without header
       2 bytes    string   1 byte     string   1 byte
       -----------------------------------------------
RRQ/  | 01/02 |  Filename  |   0  |    Mode    |   0  |
WRQ    -----------------------------------------------
       2 bytes    2 bytes       n bytes
       ---------------------------------
DATA  | 03    |   Block #  |    Data    |
       ---------------------------------
       2 bytes    2 bytes
       -------------------
ACK   | 04    |   Block #  |
       --------------------
       2 bytes  2 bytes        string    1 byte
       ----------------------------------------
ERROR | 05    |  ErrorCode |   ErrMsg   |   0  |
       ----------------------------------------
                                             15


Initial Connection Protocol for reading a file


   1. Host  A  sends  a  "RRQ"  to  host  B  with  source= A's TID,
      destination= 69.

   2. Host B sends a "DATA" (with block number= 1) to host  A  with
      source= B's TID, destination= A's TID.
                                             16


Error Codes


Value     Meaning
0         Not defined, see error message (if any).
1         File not found.
2         Access violation.
3         Disk full or allocation exceeded.
4         Illegal TFTP operation.
5         Unknown transfer ID.
6         File already exists.
7         No such user.
                                             17

                                 3
Internet User Datagram Header [2] 


  Format

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Length             |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Values of Fields


Source Port     Picked by originator of packet.


Dest. Port      Picked by destination machine (69 for RRQ or WRQ).


Length          Number of bytes in packet after Datagram header.

                                                                   4
Checksum        Reference 2 describes rules for computing checksum. 
                Field contains zero if unused.


Note:  TFTP  passes  transfer  identifiers  (TID's) to the Internet User

Datagram protocol to be used as the source and destination ports.












_______________
  3
   This has been included only  for  convenience.    TFTP  need  not  be
implemented on top of the Internet User Datagram Protocol.
  4
   The  implementor of this should be sure that the correct algorithm is
used here.
                                             18


References

  [1]     USA  Standard  Code  for  Information Interchange, USASI X3.4-

          1968.



  [2]     Postel, Jon., "User Datagram  Protocol,"  RFC768,  August  28,

          1980.


				
  [3]     "Telnet Protocol Specification," RFC764, June, 1980.