rfc1986.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,180 行 · 第 1/4 页

   +---------------+---------------+---------------+---------------+

   Table 11: CONTROL_OK Message Subtype

                     1                   2                   3
    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 2
   +---------------+---------------+---------------+---------------+
   |Subtype        |Padding        |Sequence Number                |
   +---------------+---------------+---------------+---------------+
   |Buffer Number                                                  |
   +---------------+---------------+---------------+---------------+
   |New Offered Burstsize          |New Offered Burstrate          |
   +---------------+---------------+---------------+---------------+
   |Current Control Timer Value    |*New DATA Packet size           |
   +---------------+---------------+---------------+---------------+












Polites, Wollman & Woo        Experimental                     [Page 11]

RFC 1986                         ETFTP                       August 1996


   Table 12: CONTROL_RESEND Message Subtype

                      1                   2                   3
    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 2
   +---------------+---------------+---------------+---------------+
   |Subtype        |Padding        |Sequence Number                |
   +---------------+---------------+---------------+---------------+
   |Buffer Number                                                  |
   +---------------+---------------+---------------+---------------+
   |Number of Missing Packets      |Longword Alignment Padding     |
   +---------------+---------------+---------------+---------------+
   |Packet Number (2 bytes)        |. . .                          |
   +---------------+---------------+---------------+---------------+
   |. . .                          |Longword Alignment Padding     |
   +---------------+---------------+---------------+---------------+

2.2 ETFTP COMMAND SET

   Being built from TFTP source code, ETFTP shares a significant portion
   of TFTP's design. Like TFTP, ETFTP does NOT support user password
   validation. The program does not support changing directories (i.e.
   cd), neither can it list directories, (i.e. ls). All filenames must
   be given in full paths, as relative paths are not supported. The
   internal finite state machine was modified to support NETBLT message
   types.

   The NETBLT protocol is implemented as closely as possible to what is
   described in RFC 998, with a few exceptions. The client string field
   in the OPEN message type is used to carry the filename of the file to
   be transferred. Netascii or binary transfers are both supported. If
   enabled, new packet sizes, burstsizes, and burstrates are re-
   negotiated downwards when half or more of the blocks in a buffer
   require retransmission. If 99% of the packets in a buffer is
   successfully transferred without any retransmissions, packet size is
   re-negotiated upwards.

   The interactive commands supported by the client process are similar
   to TFTP. Here is the ETFTP command set. Optional parameters are in
   square brackets. Presets are in parentheses.

   ?       help, displays command list
   ascii   mode ascii, appends CR-LF per line
   autoadapt       toggles backoff function (on)
   baudrate baud   baud rate (16000 bits/sec)
   binary  mode binary, image transfer
   blocksize bytes packet size in bytes (512 bytes/block)
   bufferblock blks        buffer size in blocks (128 blocks/buff)
   burstsize packets       burst size in packets (8 blocks/burst)



Polites, Wollman & Woo        Experimental                     [Page 12]

RFC 1986                         ETFTP                       August 1996


   connect host [p]        establish connection with host at port p
   exit    ends program
   get rfile lfile copy remote file to local file
   help    same as ?
   mode choice     set transfer mode (binary)
   multibuff num   number of buffers (2 buffers)
   put lfile rfile copy local file to remote file
   quit    same as exit
   radiodelay sec  transmission delay in seconds (2 sec)
   status  display network parameters
   trace   toggles debug display (off).

2.3 DATA TRANSFER AND FLOW CONTROL

   This is the scenario between client and server transfers:

   Client sends OPEN for connection, blocksize, buffersize, burstsize,
   burstrate, transfer mode, and get or put. See M bit of reserved
   field.

   Server sends a RESPONSE with the agreed parameters.

   Receiver sends a CONTROL_GO request sending of first buffer.

   Sender starts transfer by reading the file into multiple memory
   buffers. See Figure 1, "File Segmentation,". Each buffer is divided
   according to the number of bytes/block. Each block becomes a DATA
   packet, which is concatenated according to the blocks/burst.  Bursts
   are transmitted according to the burstrate. Last data block is
   flagged as LDATA type.

   +---+     +---+      +---+ +---+ +---+      +---+ +---+ +---+
   |   |     | 0 |      | L | | 4 | | 3 | ---- | 2 | | 1 | | 0 |
   |   |     | +---+    +---+ +---+ +---+      +---+ +---+ +---+
   |   |     +-|   | -->      +---+ +---+      +---+ +---+ +---+
   |   | -->   | 1 |          | L | | 3 | ---- | 2 | | 1 | | 0 |
   +---+       +---+          +---+ +---+      +---+ +---+ +---+
   File   Multi Buffers  Blocks per Burst

   Figure 1. File Segmentation

   Receiver acknowledges buffer as CONTROL_OK or CONTROL_RESEND.

   If blocks are missing, a CONTROL_RESEND packet is transmitted. If
   half or more of the blocks in a buffer are missing, an adaptive
   algorithm is used for the next buffer transfer. If no blocks are
   missing, a CONTROL_OK packet is transmitted.




Polites, Wollman & Woo        Experimental                     [Page 13]

RFC 1986                         ETFTP                       August 1996


   Sender re-transmits blocks until receipt of a CONTROL_OK. If the
   adaptive algorithm is set, then new parameters are offered, in the
   CONTROL_OK message. The priority of the adaptive algorithm is:

   -       Reduce packetsize by half (MIN = 16 bytes/packet)
   -       Reduce burstsize by one (MIN = 1 packet/burst)
   -       Reduce burstrate to actual tighttimer rate

   If new parameters are valid, the sender transmits a NULL-ACK packet,
   to confirm the changes.

   Receiver sends a CONTROL_GO to request sending next buffer.

   At end of transfer, sender sends a QUIT to close the connection.

   Receiver acknowledges the close request with a DONE packet.

2.4 TUNABLE PARAMETERS

   These parameters directly affect the throughput rate of ETFTP.

   Packetsize      The packetsize is the number of 8 bit bytes per
   packet. This number refers to the user data bytes in a block, (frame),
   exclusive of any network overhead. The packet size has a valid range
   from 16 to 1,448 bytes. The Maximum Transfer Unit (MTU) implemented in
   most commercial network devices is 1,500 bytes. The de-facto industry
   standard is 576 byte packets.

   Bufferblock     The bufferblock is the number of blocks per buffer.
   Each implementation may have restrictions on available memory, so the
   buffersize is calculated by multiplying the packetsize times the
   bufferblocks.

   Baudrate        The baudrate is the bits per second transfer rate of
   the slowest link (i.e., the radios). The baudrate sets the speed of
   the sending process. The sending process cannot detect the actual
   speed of the network, so the user must set the correct baudrate.

   Burstsize       The burstsize in packets per burst sets how many
   packets are concatenated and burst for transmission efficiency. The
   burstsize times the packetsize must not exceed the available memory of
   any intervening network devices. On the Ethernet portion of the
   network, all the packets are sent almost instantaneously. It is
   necessary to wait for the network to drain down its memory buffers,
   before the next burst is sent. The sending process needs to regulate
   the rate used to place packets into the network.





Polites, Wollman & Woo        Experimental                     [Page 14]

RFC 1986                         ETFTP                       August 1996


   Radiodelay      The radiodelay is the time in seconds per burst it
   takes to synchronize with the radio controllers. Any additional
   hardware delays should be set here. It is the aggregate delay of the
   link layer, such as transmitter key-up, FEC, crypto synchronization,
   and propagation delays.

   These parameters above are used to calculate a burstrate, which is the
   length of time it takes to transmit one burst. The ov is the overhead
   of 72 bytes per packet of network encapsulation. A byte is defined as
   8 bits. The burstrate value is:

     burstrate = (packetsize+ov)*burstsize*8/baudrate

   In a effort to calculate the round trip time, when data is flowing in
   one direction for most of the transfer, the OPEN and RESPONSE message
   types are timed, and the tactical radio delays are estimated. Using
   only one packet in each direction to estimate the rate of the link is
   statistically inaccurate. It was decided that the radio delay should
   be a constant provided by the user interface.  However, a default
   value of 2 seconds is used. The granularity of this value is in
   seconds because of two reasons. The first reason is that the UNIX
   supports a sleep function in seconds only. The second reason is that
   in certain applications, such as deep space probes, a 16-bit integer
   maximum of 32,767 seconds would suffice.

2.5 DELAYS AND TIMERS

   From these parameters, several timers are derived. The control timer
   is responsible for measuring the per buffer rate of transfer. The
   SENDER copy is nicknamed the loosetimer.

     loosetimer = (burstrate+radiodelay)*bufferblock/burstsize

   The RECEIVER copy of the timer is nicknamed the tighttimer, which
   measures the elapsed time between CONTROL_GO and CONTROL_OK packets.
   The tighttimer is returned to the SENDER to allow the protocol to
   adjust for the speed of the network.

   The retransmit timer is responsible for measuring the network receive
   data function. It is used to set an alarm signal (SIGALRM) to
   interrupt the network read. The retransmit timer (wait) is initially
   set to be the greater of twice the round trip or 4 times the
   radiodelay, plus a constant 5 seconds.








Polites, Wollman & Woo        Experimental                     [Page 15]

RFC 1986                         ETFTP                       August 1996


      wait = MAX ( 2*roundtriptime,  4*radiodelay ) + 5 seconds

   and

      alarm timeout = wait.

   Each time the same read times out, a five second backoff is added to
   the next wait. The backoff is necessary because the initial user
   supplied radiodelay, or the initial measured round trip time may be
   incorrect.

   The retransmit timer is set differently for the RECEIVER during a
   buffer transfer. Before the arrival of the first DATA packet, the
   original alarm time out is used. Once the DATA packets start
   arriving, and for the duration of each buffer transfer, the RECEIVER
   alarm time out is reset to the expected arrival time of the last DATA
   packet (blockstogo) plus the delay (wait). As each DATA packet is
   received, the alarm is decremented by one packet interval. This same
   algorithm is used for receiving missing packets, during a RESEND.

     alarmtimeout = blockstogo*burstrate/burstsize + wait

   The death timer is responsible for measuring the idle time of a
   connection. In the ETFTP program, the death timer is set to be equal
   to the accumulated time of ten re-transmissions plus their associated
   backoffs. As such, the death timer value in the OPEN and RESPONSE
   message types is un-necessary. In the ETFTP program, this field could
   be used to transfer the radio delay value instead of creating the two
   new fields.

   The keepalive timer is responsible for resetting the death timer.
   This timer will trigger the sending of a KEEPALIVE packet to prevent
   the remote host from closing a connection due to the expiration of
   its death timer. Due to the nature of the ETFTP server process, a
   keepalive timer was not necessary, although it is implemented.

2.6 TEST RESULTS

   The NETBLT protocol has been tested on other high speed networks