doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc1986.txt b/doc/rfc/rfc1986.txt
new file mode 100644
index 0000000..98b281a
--- /dev/null
+++ b/doc/rfc/rfc1986.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group                                         W. Polites
+Request for Comments: 1986                                    W. Wollman
+Category: Experimental                                            D. Woo
+                                                   The MITRE Corporation
+                                                               R. Langan
+                                                         U.S. ARMY CECOM
+                                                             August 1996
+
+
+    Experiments with a Simple File Transfer Protocol for Radio Links
+         using Enhanced Trivial File Transfer Protocol (ETFTP)
+
+
+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.
+
+1. INTRODUCTION SECTION
+
+   This document is a description of the Enhanced Trivial File Transfer
+   Protocol (ETFTP). This protocol is an experimental implementation of
+   the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file
+   transfer application program. It uses the User Datagram Protocol
+   (UDP), RFC 768 [2], as its transport layer. The two protocols are
+   layered to create the ETFTP client server application. The ETFTP
+   program is named after Trivial File Transfer Protocol (TFTP), RFC
+   1350 [3], because the source code from TFTP is used as the building
+   blocks for the ETFTP program. This implementation also builds on but
+   differs from the work done by the National Imagery Transmission
+   Format Standard [4].
+
+   This document is published for discussion and comment on improving
+   the throughput performance of data transfer utilities over Internet
+   Protocol (IP) compliant, half duplex, radio networks.
+
+   There are many file transfer programs available for computer
+   networks.  Many of these programs are designed for operations through
+   high-speed, low bit error rate (BER) cabled networks. In tactical
+   radio networks, traditional file transfer protocols, such as File
+   Transfer Protocol (FTP) and TFTP, do not always perform well. This is
+   primarily because tactical half duplex radio networks typically
+   provide slow-speed, long delay, and high BER communication links.
+   ETFTP is designed to allow a user to control transmission parameters
+   to optimize file transfer rates through half-duplex radio links.
+
+
+
+
+Polites, Wollman & Woo        Experimental                      [Page 1]
+
+RFC 1986                         ETFTP                       August 1996
+
+
+   The tactical radio network used to test this application was
+   developed by the Survivable Adaptive Systems (SAS) Advanced
+   Technology Demonstration (ATD). Part of the SAS ATD program was to
+   address the problems associated with extending IP networks across
+   tactical radios.  Several tactical radios, such as, SINgle Channel
+   Ground and Airborne Radio Systems (SINCGARS), Enhanced Position
+   Location Reporting Systems (EPLRS), Motorola LST-5C, and High
+   Frequency (HF) radios have been interfaced to the system.  This
+   document will discuss results obtained from using ETFTP across a
+   point-to-point LST-5C tactical SATellite COMmunications (SATCOM)
+   link. The network includes a 25 Mhz 486 Personal Computer (PC) called
+   the Army Lightweight Computer Unit (LCU), Cisco 2500 routers,
+   Gracilis PackeTen Network switches, Motorola Sunburst Cryptographic
+   processors, a prototype forward error correction (FEC) device, and
+   Motorola LST-5C tactical Ultra High Frequency (UHF) satellite
+   communications (SATC!  OM) radio. Table 1, "Network Trans fer Rates,"
+   describes the equipment network connections and the bandwidth of the
+   physical media interconnecting the devices.
+
+   Table 1: Network Transfer Rates
+
+   +-------------------------------+-------------------------------+
+   | Equipment                     | Rate (bits per second)        |
+   +-------------------------------+-------------------------------+
+   | Host Computer (486 PC)        | 10,000,000 Ethernet           |
+   +-------------------------------+-------------------------------+
+   | Cisco Router                  | 10,000,000 Ethernet to        |
+   |                               | 19,200 Serial Line Internet   |
+   |                               | Protocol (SLIP)               |
+   +-------------------------------+-------------------------------+
+   | Gracilis PackeTen             | 19,200 SLIP to                |
+   |                               | 16,000 Amateur Radio (AX.25)  |
+   +-------------------------------+-------------------------------+
+   | FEC                           | half rate or quarter rate     |
+   +-------------------------------+-------------------------------+
+   | Sunburst Crypto               | 16,000                        |
+   +-------------------------------+-------------------------------+
+   | LST-5C Radio                  | 16,000                        |
+   +-------------------------------+-------------------------------+
+
+   During 1993, the MITRE team collected data for network configurations
+   that were stationary and on-the-move. This network configuration did
+   not include any Forward Error Correction (FEC) at the link layer.
+   Several commercially available implementations of FTP were used to
+   transfer files through a 16 kbps satellite link. FTP relies upon the
+   Transmission Control Protocol (TCP) for reliable communications.  For
+   a variety of file sizes, throughput measurements ranged between 80
+   and 400 bps. At times, TCP connections could be opened, however, data
+
+
+
+Polites, Wollman & Woo        Experimental                      [Page 2]
+
+RFC 1986                         ETFTP                       August 1996
+
+
+   transfers would be unsuccessful. This was most likely due to the
+   smaller TCP connection synchronization packets, as compared to the
+   TCP data packets.  Because of the high bit error rate of the link,
+   the smaller packets were much more likely to be received without
+   error. In most cases, satellite channel utilization was less than 20
+   percent.  Very often a file transfer would fail because FTP
+   implementations would curtail the transfer due t!  o the poor
+   conditions of the commu nication link.
+
+   The current focus is to increase the throughput and channel
+   utilization over a point to point, half duplex link. Follow on
+   experiments will evaluate ETFTP's ability to work with multiple hosts
+   in a multicast scenario. Evaluation of the data collected helped to
+   determine that several factors limited data throughput. A brief
+   description of those limiting factors, as well as, solutions that can
+   reduce these networking limitations is provided below.
+
+Link Quality
+
+   The channel quality of a typical narrow-band UHF satellite link does
+   not sufficiently support data communications without the addition of
+   a forward error correction (FEC) capability.  From the data
+   collected, it was determined that the UHF satellite link supports, on
+   average, a 10e-3 bit error rate.
+
+   Solution: A narrow-band UHF satellite radio FEC prototype was
+   developed that improves data reliability, without excessively
+   increasing synchronization requirements. The prototype FEC increased
+   synchronization requirements by less than 50 milliseconds (ms). The
+   FEC implementation will improve an average 10e-3 BER channel to an
+   average 10e-5 BER channel.
+
+Delays
+
+   Including satellite propagation delays, the tactical satellite radios
+   require approximately 1.25 seconds for radio synchronization prior to
+   transmitting any data across the communication channel.  Therefore,
+   limiting the number of channel accesses required will permit data
+   throughput to increase. This can be achieved by minimizing the number
+   of acknowledgments required during the file transfer.  FTP generates
+   many acknowledgments which decreases throughput by increasing the
+   number of satellite channel accesses required.
+
+   To clarify, when a FTP connection request is generated, it is sent
+   via Ethernet to the router and then forwarded to the radio network
+   controller (RNC).  The elapsed time is less than 30 ms. The RNC keys
+   the crypto unit and 950 ms later modem/crypto synchronization occurs.
+   After synchronization is achieved, the FTP connection request is
+
+
+
+Polites, Wollman & Woo        Experimental                      [Page 3]
+
+RFC 1986                         ETFTP                       August 1996
+
+
+   transmitted. The transmitting terminal then drops the channel and the
+   modem/crypto synchronization is lost. Assuming that the request was
+   received successfully, the receiving host processes the request and
+   sends an acknowledgment. Again the modem/crypto have to synchronize
+   prior to transmitting the acknowledgment. Propagation delays over a
+   UHF satellite also adds roughly 500 ms to the total round trip delay.
+
+   Solution: When compared to FTP, NETBLT significantly reduces the
+   number of acknowledgments required to complete a file transfer.
+   Therefore, leveraging the features available within an implementation
+   of NETBLT will significantly improve throughput across the narrow-
+   band UHF satellite communication link.
+
+   To reduce the number of channel accesses required, a number of AX.25
+   parameters were modified.  These included the value of p for use
+   within the p-persistence link layer protocol, the slot time, the
+   transmit tail time, and the transmit delay time.  The p-persistence
+   is a random number threshold between 0 and 255.  The slot time is the
+   time to wait prior to attempting to access the channel.  The transmit
+   tail increases the amount of time the radio carrier is held on, prior
+   to dropping the channel. Transmit delay is normally equal to the
+   value of the radio synchronization time.  By adjusting these
+   parameters to adapt to the tactical satellite environment, improved
+   communication performance can be achieved.
+
+   First, in ETFTP, several packets within a buffer are transmitted
+   within one burst. If the buffer is partitioned into ten packets, each
+   of 1024 bytes, then 10,240 bytes of data is transmitted with each
+   channel access. It is possible to configure ETFTP's burstsize to
+   equal the number of packets per buffer. Second, the transmit tail
+   time was increased to hold the key down on the transmitter long
+   enough to insure all of the packets within the buffer are sent in a
+   single channel access. These two features, together, allow the system
+   to transmit an entire file (example, 100,000 bytes) with only a
+   single channel access by adjusting buffer size. Thirdly, the ETFTP
+   protocol only acknowledges each buffer, not each packet. Thus, a
+   single acknowledgment is sent from the receiving terminal containing
+   a request for the missing packets within each buffer, reducing the
+   number of acknowledgment packets sent. Which in turn, reduced the
+   number of times the channel has to be turned around.
+
+   To reduce channel access time, p-persistence was set to the maximum
+   value and slot time to a minimum value. These settings support
+   operations for a point-to-point communication link between two users.
+   This value of p would not be used if more users were sharing the
+   satellite channel.
+
+
+
+
+
+Polites, Wollman & Woo        Experimental                      [Page 4]
+
+RFC 1986                         ETFTP                       August 1996
+
+
+Backoffs
+
+   TCP's slow start and backoff algorithms implemented in most TCP
+   packages assume that packet loss is due to network congestion.  When
+   operating across a tactical half duplex communication channel
+   dedicated to two users, packet loss is primarily due to poor channel
+   quality, not network congestion. A linear backoff at the transport
+   layer is recommended. In a tactical radio network there are numerous
+   cases where a single host is connected to multiple radios. In a
+   tactical radio network, layer two will handle channel access.
+   Channel access will be adjusted through parameters like p-persistence
+   and slot time. The aggregate effect of the exponential backoff from
+   the transport layer added to the random backoff of the data link
+   layer, will in most cases, cause the radio network to miss many
+   network access opportunities. A linear backoff will reduce the number
+   missed data link network access opportunities
+
+   Solution: Tunable parameters and timers have been modified to
+   resemble those suggested by NETBLT.
+
+Packet Size
+
+   In a tactical environment, channel conditions change rapidly.
+   Continuously transmitting large packets under 10e-3 BER conditions
+   reduces effective throughput.
+
+   Solution: Packet sizes are dynamically adjusted based upon the
+   success of the buffer transfers. If 99 percent of all packets within
+   a buffer are received successfully, packet size can be increased to a
+   negotiated value.  If 50 percent or more of all packets within a
+   buffer are not successfully delivered, the packet size can be
+   decreased to a negotiated value.
+
+2. PROTOCOL DESCRIPTION
+
+   Throughout this document the term packet is used to describe a
+   datagram that includes all network overhead. A block is used to
+   describe information, without any network encapsulation.
+
+   The original source files for TFTP, as downloaded from ftp.uu.net,
+   were modified to implement the ETFTP/NETBLT protocol. These same
+   files are listed in "UNIX Network Programming" [5].
+
+   ETFTP was implemented for operations under the Santa Cruz Operations
+   (SCO) UNIX. In the service file, "/etc/services", an addition was
+   made to support "etftp" at a temporary well known port of "1818"
+   using "UDP" protocol. The file, "/etc/inetd.conf", was modified so
+   the "inetd" program could autostart the "etftpd" server when a
+
+
+
+Polites, Wollman & Woo        Experimental                      [Page 5]
+
+RFC 1986                         ETFTP                       August 1996
+
+
+   connection request came in on the well known port.
+
+   As stated earlier, the transport layer for ETFTP is UDP, which will
+   not be discussed further here. This client server application layer
+   protocol is NETBLT, with four notable differences.
+
+   The first change is that this NETBLT protocol is implemented on top
+   of the UDP layer. This allowed the NETBLT concepts to be tested
+   without modifying the operating system's transport or network layers.
+   Table 2, "Four Layer Protocol Model," shows the protocol stack for
+   FTP, TFTP and ETFTP.
+
+   Table 2: Four Layer Protocol Model
+
+   +---------------------------------------------------------------+
+   |                         PROTOCOL STACK                        |
+   +---------------+---------------+---------------+---------------+
+   |APPLICATION    |FTP            |TFTP           |ETFTP/NETBLT   |
+   +---------------+---------------+---------------+---------------+
+   |TRANSPORT      |TCP            |UDP            |UDP            |
+   +---------------+---------------+---------------+---------------+
+   |NETWORK        |IP                                             |
+   +---------------+---------------+---------------+---------------+
+   |LINK           |Ethernet, SLIP, AX.25                          |
+   +---------------+---------------+---------------+---------------+
+
+   The second change is a carryover from TFTP, which allows files to be
+   transferred in netascii or binary modes. A new T bit flag is assigned
+   to the reserved field of the OPEN message type.
+
+   The third change is to re-negotiate the DATA packet size. This change
+   affects the OPEN, NULL-ACK, and CONTROL_OK message types.  A new R
+   bit is assigned to the reserved field of the OPEN message type.
+
+   The fourth change is the addition of two new fields to the OPEN
+   message type. The one field is a two byte integer for radio delay in
+   seconds, and the next field is two bytes of padding.
+
+   The ETFTP data encapsulation is shown in Table 3, "ETFTP Data
+   Encapsulation,". The Ethernet, SLIP, and AX.25 headers are mutually
+   exclusive. They are stripped off and added by the appropriate
+   hardware layer.
+
+
+
+
+
+
+
+
+
+Polites, Wollman & Woo        Experimental                      [Page 6]
+
+RFC 1986                         ETFTP                       August 1996
+
+
+   Table 3: ETFTP Data Encapsulation
+
+   +------------+------------+------------+------------+-----------+
+   |Ethernet(14)|            |            |ETFTP/      |           |
+   |SLIP(2)     |IP(20)      |UDP(8)      |NETBLT(24)  |DATA(1448) |
+   |AX.25(20)   |            |            |            |           |
+   +------------+------------+------------+------------+-----------+
+
+2.1     MESSAGE TYPES AND FORMATS
+
+   Here are the ETFTP/NETBLT message types and formats.
+
+   MESSAGES        VALUES
+   OPEN    0  Client request to open a new connection
+   RESPONSE        1  Server positive acknowledgment for OPEN
+   KEEPALIVE       2  Reset the timer
+   QUIT    3  Sender normal Close request
+   QUITACK 4  Receiver acknowledgment of QUIT
+   ABORT   5  Abnormal close
+   DATA    6  Sender packet containing data
+   LDATA   7  Sender last data block of a buffer
+   NULL-ACK        8  Sender confirmation of CONTROL_OK changes
+   CONTROL 9  Receiver request to
+           GO      0 Start transmit of next buffer
+           OK      1 Acknowledge complete buffer
+           RESEND  2 Retransmit request
+   REFUSED 10 Server negative acknowledgment of OPEN
+   DONE    11 Receiver acknowledgment of QUIT.
+
+   Packets are "longword-aligned", at four byte word boundaries.
+   Variable length strings are NULL terminated, and padded to the four
+   byte boundary. Fields are listed in network byte order. All the
+   message types share a common 12 byte header. The common fields are:
+
+   Checksum        IP compliant checksum
+   Version Current version ID
+   Type    NETBLT message type
+   Length  Total byte length of packet
+   Local Port      My port ID
+   Foreign Port    Remote port ID
+   Padding Pad as necessary to 4 byte boundary
+
+   The OPEN and RESPONSE messages are similar and shown in Table 4,
+   "OPEN and RESPONSE Message Types,". The client string field is used
+   to carry the filename to be transferred.
+
+
+
+
+
+
+Polites, Wollman & Woo        Experimental                      [Page 7]
+
+RFC 1986                         ETFTP                       August 1996
+
+
+   Table 4: OPEN and RESPONSE Message Types
+
+                      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
+   +---------------+---------------+---------------+---------------+
+   |Checksum                       |Version        |Type           |
+   +---------------+---------------+---------------+---------------+
+   |Length                         |Local Port                     |
+   +---------------+---------------+---------------+---------------+
+   |Foreign Port                   |Longword Alignment Padding     |
+   +---------------+---------------+---------------+---------------+
+   |Connection ID                                                  |
+   +---------------+---------------+---------------+---------------+
+   |Buffer size                                                     |
+   +---------------+---------------+---------------+---------------+
+   |Transfer size                                                   |
+   +---------------+---------------+---------------+---------------+
+   |DATA Packet size                |Burstsize                      |
+   +---------------+---------------+---------------+---------------+
+   |Burstrate                      |Death Timer Value              |
+   +---------------+---------------+---------------+---------------+
+   |Reserved(MBZ)          |R|T|C|M|Maximum # Outstanding Buffers  |
+   +---------------+---------------+---------------+---------------+
+   |*Radio Delay                   |*Padding                       |
+   +---------------+---------------+---------------+---------------+
+   |Client String . . .            |Longword Alignment Padding     |
+   +---------------+---------------+---------------+---------------+
+
+   Connection ID   The unique connection number
+   Buffer size     Bytes per buffer
+   Transfer size   The length of the file in bytes
+   DATA Packet size        Bytes per ETFTP block
+   Burstsize       Concatenated packets per burst
+   Burstrate       Milliseconds per burst
+   Death Timer     Seconds before closing idle links
+   Reserved        M bit is mode: 0=read/put, 1=write/get
+           C bit is checksum: 0=header, 1=all
+           *T bit is transfer: 0=netascii, 1=binary
+           *R bit is re-negotiate: 0=off, 1=on
+   Max # Out Buffs Maximum allowed un-acknowledged buffers
+   Radio Delay     *Seconds of delay from send to receive
+   Padding *Unused
+   Client String   Filename.
+
+   The KEEPALIVE, QUITACK, and DONE messages are identical to the common
+   header, except for the message type values. See Table 5, "KEEPALIVE,
+   QUITACK, and DONE Message Types,".
+
+
+
+
+Polites, Wollman & Woo        Experimental                      [Page 8]
+
+RFC 1986                         ETFTP                       August 1996
+
+
+   Table 5: KEEPALIVE, QUITACK, and DONE Message Types
+
+                      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
+   +---------------+---------------+---------------+---------------+
+   |Checksum                       |Version        |Type           |
+   +---------------+---------------+---------------+---------------+
+   |Length                         |Local Port                     |
+   +---------------+---------------+---------------+---------------+
+   |Foreign Port                   |Longword Alignment Padding     |
+   +---------------+---------------+---------------+---------------+
+
+
+   The QUIT, ABORT, and REFUSED messages allow a string field to carry
+   the reason for the message. See Table 6, "QUIT, ABORT, and REFUSED
+   Message Types,".
+
+   Table 6: QUIT, ABORT, and REFUSED Message Types
+
+                      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
+   +---------------+---------------+---------------+---------------+
+   |Checksum                       |Version        |Type           |
+   +---------------+---------------+---------------+---------------+
+   |Length                         |Local Port                     |
+   +---------------+---------------+---------------+---------------+
+   |Foreign Port                   |Longword Alignment Padding     |
+   +---------------+---------------+---------------+---------------+
+   |Reason for QUIT/ABORT/REFUSED . . .                            |
+   +---------------+---------------+---------------+---------------+
+   |. . .                          |Longword Alignment Padding     |
+   +---------------+---------------+---------------+---------------+
+
+   The DATA and LDATA messages make up the bulk of the messages
+   transferred. The last packet of each buffer is flagged as an LDATA
+   message. Each and every packet of the last buffer has the reserved L
+   bit set. The highest consecutive sequence number is used for the
+   acknowledgment of CONTROL messages. It should contain the ID number
+   of the current CONTROL message being processed. Table 7, "DATA and
+   LDATA Message Types,", shows the DATA and LDATA formats.
+
+
+
+
+
+
+
+
+
+
+
+Polites, Wollman & Woo        Experimental                      [Page 9]
+
+RFC 1986                         ETFTP                       August 1996
+
+
+   Table 7: DATA and LDATA Message Types
+
+                      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
+   +---------------+---------------+---------------+---------------+
+   |Checksum                       |Version        |Type           |
+   +---------------+---------------+---------------+---------------+
+   |Length                         |Local Port                     |
+   +---------------+---------------+---------------+---------------+
+   |Foreign Port                   |Longword Alignment Padding     |
+   +---------------+---------------+---------------+---------------+
+   |Buffer Number                                                  |
+   +---------------+---------------+---------------+---------------+
+   |High Consecutive Seq Num Rcvd  |Packet Number                  |
+   +---------------+---------------+---------------+---------------+
+   |Data Area Checksum Value       |Reserved (MBZ)               |L|
+   +---------------+---------------+---------------+---------------+
+
+   Buffer Number   The first buffer number starts at 0
+   Hi Con Seq Num  The acknowledgment for CONTROL messages
+   Packet Number   The first packet number starts at 0
+   Data Checksum   Checksum for data area only
+   Reserved        L: the last buffer bit: 0=false, 1=true
+
+   The NULL-ACK message type is sent as a response to a CONTROL_OK
+   message that modifies the current packet size, burstsize, or
+   burstrate. In acknowledging the CONTROL_OK message, the sender is
+   confirming the change request to the new packet size, burstsize, or
+   burstrate. If no modifications are requested, a NULL-ACK message is
+   unnecessary. See Table 8, "NULL-ACK Message Type," for further
+   details.
+
+   Table 8: NULL-ACK Message Type
+
+                      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
+   +---------------+---------------+---------------+---------------+
+   |Checksum                       |Version        |Type           |
+   +---------------+---------------+---------------+---------------+
+   |Length                         |Local Port                     |
+   +---------------+---------------+---------------+---------------+
+   |Foreign Port                   |Longword Alignment Padding     |
+   +---------------+---------------+---------------+---------------+
+   |High Consecutive Seq Num Rcvd  |New Burstsize                  |
+   +---------------+---------------+---------------+---------------+
+   |New Burstrate                  |*New DATA Packet size           |
+   +---------------+---------------+---------------+---------------+
+
+
+
+
+Polites, Wollman & Woo        Experimental                     [Page 10]
+
+RFC 1986                         ETFTP                       August 1996
+
+
+   The CONTROL messages have three subtypes: GO, OK, and RESEND as shown
+   in Tables 9-12. The CONTROL message common header may be followed by
+   any number of longword aligned subtype messages.
+
+   Table 9: CONTROL Message Common Header
+
+                      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
+   +---------------+---------------+---------------+---------------+
+   |Checksum                       |Version        |Type           |
+   +---------------+---------------+---------------+---------------+
+   |Length                         |Local Port                     |
+   +---------------+---------------+---------------+---------------+
+   |Foreign Port                   |Longword Alignment Padding     |
+   +---------------+---------------+---------------+---------------+
+
+   Table 10: CONTROL_GO 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                                                  |
+   +---------------+---------------+---------------+---------------+
+
+   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
+   before, see RFC 1030 [6]. These test results in Tables 13 and 14,
+   "ETFTP Performance," were gathered from files transferred across the
+   network and LST-5C TACSAT radios.  The radios were connected together
+   via a coaxial cable to provide a "clean" link. A clean link is
+   defined to a BER of 10e-5. The throughput rates are defined to be the
+   file size divided by the elapsed time resulting in bits per second
+   (bps).  The elapsed time is measured from the time of the "get" or
+   "put" command to the completion of the transfer. This is an all
+   inclusive time measurement based on user perspective. It includes the
+
+
+
+Polites, Wollman & Woo        Experimental                     [Page 16]
+
+RFC 1986                         ETFTP                       August 1996
+
+
+   connection time, transfer time, error recovery time, and disconnect
+   time. The user concept of elapsed time is the length of time it takes
+   to copy a file from disk to disk. These results show only the average
+   performances, including the occasional packet re-transmissions. The
+   network configuration was set as:
+
+   ETFTP Parameters:
+
+   Filesize                101,306 bytes
+   Radiodelay      2 seconds
+   Buffersize      16,384-131,072 bytes
+   Packetsize      512-2048 bytes
+   Burstsize               8-16 packets/burst
+
+   Gracilis PackeTen Parameters:
+
+   0 TX Delay      400 milliseconds
+   1 P Persist     255 [range 1-255]
+   2 Slot Time     30 milliseconds
+   3 TX Tail               300 milliseconds
+   4 Rcv Buffers   8 2048 bytes/buffer
+   5 Idle Code     Flag
+
+   Radio Parameters:
+
+   Baudrate                16,000 bps
+   Encryption      on
+
+
+   Table 13: ETFTP Performance at 8 Packets/Burst in Bits/Second
+
+   +-----------+-----------+-----------+-----------+-----------+
+   |buffersize |packetsize |packetsize |packetsize |packetsize |
+   |(bytes)    |2,048 bytes|1,448 bytes|1,024 bytes|512 bytes  |
+   +-----------+-----------+-----------+-----------+-----------+
+   |    16,384 |     7,153 |     6,952 |     6,648 |     5,248 |
+   +-----------+-----------+-----------+-----------+-----------+
+   |    32,768 |     7,652 |     7,438 |     7,152 |     4,926 |
+   +-----------+-----------+-----------+-----------+-----------+
+   |    65,536 |     8,072 |     8,752 |     8,416 |     5,368 |
+   +-----------+-----------+-----------+-----------+-----------+
+   |   131,072 |     8,828 |     9,112 |     7,888 |     5,728 |
+   +-----------+-----------+-----------+-----------+-----------+
+
+
+
+
+
+
+
+
+Polites, Wollman & Woo        Experimental                     [Page 17]
+
+RFC 1986                         ETFTP                       August 1996
+
+
+   Table 14: ETFTP Performance at 16 Packets/Burst in Bits/Second
+
+   +-----------+-----------+-----------+-----------+-----------+
+   |buffersize |packetsize |packetsize |packetsize |packetsize |
+   |(bytes)    |2,048 bytes|1,448 bytes|1,024 bytes|512 bytes  |
+   +-----------+-----------+-----------+-----------+-----------+
+   |    16,384 |     5,544 |     5,045 |     4,801 |     4,570 |
+   +-----------+-----------+-----------+-----------+-----------+
+   |    32,768 |     8,861 |     8,230 |     8,016 |     7,645 |
+   +-----------+-----------+-----------+-----------+-----------+
+   |    65,536 |     9,672 |     9,424 |     9,376 |     8,920 |
+   +-----------+-----------+-----------+-----------+-----------+
+   |   131,072 |    10,432 |    10,168 |     9,578 |     9,124 |
+   +-----------+-----------+-----------+-----------+-----------+
+
+2.7 PERFORMANCE CONSIDERATIONS
+
+   These tests were performed across a tactical radio link with a
+   maximum data rate of 16000 bps. In testing ETFTP, it was found that
+   the delay associated with the half duplex channel turnaround time was
+   the biggest factor in throughput performance. Therefore, every
+   attempt was made to minimize the number of times the channel needed
+   to be turned around. Obviously, the easiest thing to do is to use as
+   big a buffer as necessary to read in a file, as acknowledgments
+   occurred only at the buffer boundaries. This is not always feasible,
+   as available storage on disk could easily exceed available memory.
+   However, the current ETFTP buffersize is set at a maximum of 524,288
+   bytes.
+
+   The larger packetsizes also improved performance. The limit on
+   packetsize is based on the 1500 byte MTU of network store and forward
+   devices. In a high BER environment, a large packetsize could be
+   detrimental to success. By reducing the packetsize, even though it
+   negatively impacts performance, reliability is sustained. When used
+   in conjunction with FEC, both performance and reliability can be
+   maintained at an acceptable level.
+
+   The burstsize translates into how long the radio transmitters are
+   keyed to transmit. In ETFTP, the ideal situation is to have the first
+   packet of a burst arrive in the radio transmit buffer, as the last
+   packet of the previous burst is just finished being sent. In this
+   way, the radio transmitter would never be dropped for the duration of
+   one buffer. In a multi-user radio network, a full buffer transmission
+   would be inconsiderate, as the transmit cycle could last for several
+   minutes, instead of seconds. In measuring voice communications,
+   typical transmit durations are on the order of five to twenty
+   seconds.  This means that the buffersize and burstsize could be
+   adjusted to have similar transmission durations.
+
+
+
+Polites, Wollman & Woo        Experimental                     [Page 18]
+
+RFC 1986                         ETFTP                       August 1996
+
+
+3.  REFERENCE SECTION
+
+   [1] Clark, D., Lambert, M., and L. Zhang,
+       "NETBLT: A Bulk Data Transfer Protocol", RFC 998, MIT,
+       March 1987.
+
+   [2] Postel, J., "User Datagram Protocol" STD 6, RFC 768,
+       USC/Information Sciences Institute, August 1980.
+
+   [3] Sollins, K., "Trivial File Transfer Protocol", STD 33,
+       RFC 1350, MIT, July 1992.
+
+   [4] MIL-STD-2045-44500, 18 June 1993, "Military Standard Tactical
+       Communications Protocol 2 (TACO 2) fot the National Imagery
+       Transmission Format Standard", Ft. Monmouth, New Jersey.
+
+   [5] Stevens, W. Richard, 1990, "UNIX Network Programming",
+       Prentice-Hall Inc., Englewood, New Jersey, Chapter 12.
+
+   [6] Lambert, M., "On Testing the NETBLT Protocol over
+       Divers Networks", RFC 1030, MIT, November 1987.
+
+4.  SECURITY CONSIDERATIONS
+
+   The ETFTP program is a security loophole in any UNIX environment.
+   There is no user/password validation. All the problems associated to
+   TFTP are repeated in ETFTP. The server program must be owned by root
+   and setuid to root in order to work. As an experimental prototype
+   program, the security issue was overlooked. Since this protocol has
+   proven too be a viable solution in tactical radio networks, the
+   security issues will have to be addressed, and corrected.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Polites, Wollman & Woo        Experimental                     [Page 19]
+
+RFC 1986                         ETFTP                       August 1996
+
+
+5.  AUTHORS' ADDRESSES
+
+   William J. Polites
+   The Mitre Corporation
+   145 Wyckoff Rd.
+   Eatontown, NJ 07724
+
+   Phone: (908) 544-1414
+   EMail:wpolites@mitre.org
+
+
+   William Wollman
+   The Mitre Corporation
+   145 Wyckoff Rd.
+   Eatontown, NJ 07724
+
+   Phone: (908) 544-1414
+   EMail:wwollman@mitre.org
+
+
+   David Woo
+   The Mitre Corporation
+   145 Wyckoff Rd.
+   Eatontown, NJ 07724
+
+   Phone: (908) 544-1414
+   EMail: dwoo@mitre.org
+
+
+   Russ Langan
+   U.S. Army Communications Electronics Command (CECOM)
+   AMSEL-RD-ST-SP
+   ATTN: Russell Langan
+   Fort Monmouth, NJ 07703
+
+   Phone: (908) 427-2064
+   Fax: (908) 427-2822
+   EMail: langanr@doim6.monmouth.army.mil
+
+
+
+
+
+
+
+
+
+
+
+
+
+Polites, Wollman & Woo        Experimental                     [Page 20]
+
+RFC 1986                         ETFTP                       August 1996
+
+
+6.  GLOSSARY
+
+   ATD             Advanced Technology Demonstration
+   AX.25           Amateur Radio X.25 Protocol
+   BER             Bit Error Rate
+   EPLRS           Enhanced Position Location Reporting Systems
+   ETFTP           Enhanced Trivial File Transfer Protocol
+   FEC             Forward Error Correction
+   FTP             File Transfer Protocol
+   HF              High Frequency
+   LCU             Lightweight Computer Unit
+   ms              milliseconds
+   MTU             Maximum Transfer Unit
+   NETBLT  NETwork Block Transfer protocol
+   NITFS           National Imagery Transmission Format Standard
+   PC              Personal Computer
+   RNC             Radio Network Controller
+   SAS             Survivable Adaptive Systems
+   SATCOM  SATellite COMmunications
+   SCO             Santa Cruz Operations
+   SINCGARS        SINgle Channel Ground and Airborne Radio Systems
+   SLIP            Serial Line Internet Protocol
+   TACO2           Tactical Communications Protocol 2
+   TCP             Transmission Control Protocol
+   TFTP            Trivial File Transfer Protocol
+   UDP             User Datagram Protocol
+   UHF             Ultra High Frequency
+
+   * Modification from NETBLT RFC 998.
+   * The new packet size is a modification to the NETBLT RFC 998.
+   * The new packet size is a modification to the NETBLT RFC 998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Polites, Wollman & Woo        Experimental                     [Page 21]
+