home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1986.txt < prev    next >
Text File  |  1996-08-16  |  51KB  |  1,180 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         W. Polites
  8. Request for Comments: 1986                                    W. Wollman
  9. Category: Experimental                                            D. Woo
  10.                                                    The MITRE Corporation
  11.                                                                R. Langan
  12.                                                          U.S. ARMY CECOM
  13.                                                              August 1996
  14.  
  15.  
  16.     Experiments with a Simple File Transfer Protocol for Radio Links
  17.          using Enhanced Trivial File Transfer Protocol (ETFTP)
  18.  
  19.  
  20. Status of this Memo
  21.  
  22.    This memo defines an Experimental Protocol for the Internet
  23.    community.  This memo does not specify an Internet standard of any
  24.    kind.  Discussion and suggestions for improvement are requested.
  25.    Distribution of this memo is unlimited.
  26.  
  27. 1. INTRODUCTION SECTION
  28.  
  29.    This document is a description of the Enhanced Trivial File Transfer
  30.    Protocol (ETFTP). This protocol is an experimental implementation of
  31.    the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file
  32.    transfer application program. It uses the User Datagram Protocol
  33.    (UDP), RFC 768 [2], as its transport layer. The two protocols are
  34.    layered to create the ETFTP client server application. The ETFTP
  35.    program is named after Trivial File Transfer Protocol (TFTP), RFC
  36.    1350 [3], because the source code from TFTP is used as the building
  37.    blocks for the ETFTP program. This implementation also builds on but
  38.    differs from the work done by the National Imagery Transmission
  39.    Format Standard [4].
  40.  
  41.    This document is published for discussion and comment on improving
  42.    the throughput performance of data transfer utilities over Internet
  43.    Protocol (IP) compliant, half duplex, radio networks.
  44.  
  45.    There are many file transfer programs available for computer
  46.    networks.  Many of these programs are designed for operations through
  47.    high-speed, low bit error rate (BER) cabled networks. In tactical
  48.    radio networks, traditional file transfer protocols, such as File
  49.    Transfer Protocol (FTP) and TFTP, do not always perform well. This is
  50.    primarily because tactical half duplex radio networks typically
  51.    provide slow-speed, long delay, and high BER communication links.
  52.    ETFTP is designed to allow a user to control transmission parameters
  53.    to optimize file transfer rates through half-duplex radio links.
  54.  
  55.  
  56.  
  57.  
  58. Polites, Wollman & Woo        Experimental                      [Page 1]
  59.  
  60. RFC 1986                         ETFTP                       August 1996
  61.  
  62.  
  63.    The tactical radio network used to test this application was
  64.    developed by the Survivable Adaptive Systems (SAS) Advanced
  65.    Technology Demonstration (ATD). Part of the SAS ATD program was to
  66.    address the problems associated with extending IP networks across
  67.    tactical radios.  Several tactical radios, such as, SINgle Channel
  68.    Ground and Airborne Radio Systems (SINCGARS), Enhanced Position
  69.    Location Reporting Systems (EPLRS), Motorola LST-5C, and High
  70.    Frequency (HF) radios have been interfaced to the system.  This
  71.    document will discuss results obtained from using ETFTP across a
  72.    point-to-point LST-5C tactical SATellite COMmunications (SATCOM)
  73.    link. The network includes a 25 Mhz 486 Personal Computer (PC) called
  74.    the Army Lightweight Computer Unit (LCU), Cisco 2500 routers,
  75.    Gracilis PackeTen Network switches, Motorola Sunburst Cryptographic
  76.    processors, a prototype forward error correction (FEC) device, and
  77.    Motorola LST-5C tactical Ultra High Frequency (UHF) satellite
  78.    communications (SATC!  OM) radio. Table 1, "Network Trans fer Rates,"
  79.    describes the equipment network connections and the bandwidth of the
  80.    physical media interconnecting the devices.
  81.  
  82.    Table 1: Network Transfer Rates
  83.  
  84.    +-------------------------------+-------------------------------+
  85.    | Equipment                     | Rate (bits per second)        |
  86.    +-------------------------------+-------------------------------+
  87.    | Host Computer (486 PC)        | 10,000,000 Ethernet           |
  88.    +-------------------------------+-------------------------------+
  89.    | Cisco Router                  | 10,000,000 Ethernet to        |
  90.    |                               | 19,200 Serial Line Internet   |
  91.    |                               | Protocol (SLIP)               |
  92.    +-------------------------------+-------------------------------+
  93.    | Gracilis PackeTen             | 19,200 SLIP to                |
  94.    |                               | 16,000 Amateur Radio (AX.25)  |
  95.    +-------------------------------+-------------------------------+
  96.    | FEC                           | half rate or quarter rate     |
  97.    +-------------------------------+-------------------------------+
  98.    | Sunburst Crypto               | 16,000                        |
  99.    +-------------------------------+-------------------------------+
  100.    | LST-5C Radio                  | 16,000                        |
  101.    +-------------------------------+-------------------------------+
  102.  
  103.    During 1993, the MITRE team collected data for network configurations
  104.    that were stationary and on-the-move. This network configuration did
  105.    not include any Forward Error Correction (FEC) at the link layer.
  106.    Several commercially available implementations of FTP were used to
  107.    transfer files through a 16 kbps satellite link. FTP relies upon the
  108.    Transmission Control Protocol (TCP) for reliable communications.  For
  109.    a variety of file sizes, throughput measurements ranged between 80
  110.    and 400 bps. At times, TCP connections could be opened, however, data
  111.  
  112.  
  113.  
  114. Polites, Wollman & Woo        Experimental                      [Page 2]
  115.  
  116. RFC 1986                         ETFTP                       August 1996
  117.  
  118.  
  119.    transfers would be unsuccessful. This was most likely due to the
  120.    smaller TCP connection synchronization packets, as compared to the
  121.    TCP data packets.  Because of the high bit error rate of the link,
  122.    the smaller packets were much more likely to be received without
  123.    error. In most cases, satellite channel utilization was less than 20
  124.    percent.  Very often a file transfer would fail because FTP
  125.    implementations would curtail the transfer due t!  o the poor
  126.    conditions of the commu nication link.
  127.  
  128.    The current focus is to increase the throughput and channel
  129.    utilization over a point to point, half duplex link. Follow on
  130.    experiments will evaluate ETFTP's ability to work with multiple hosts
  131.    in a multicast scenario. Evaluation of the data collected helped to
  132.    determine that several factors limited data throughput. A brief
  133.    description of those limiting factors, as well as, solutions that can
  134.    reduce these networking limitations is provided below.
  135.  
  136. Link Quality
  137.  
  138.    The channel quality of a typical narrow-band UHF satellite link does
  139.    not sufficiently support data communications without the addition of
  140.    a forward error correction (FEC) capability.  From the data
  141.    collected, it was determined that the UHF satellite link supports, on
  142.    average, a 10e-3 bit error rate.
  143.  
  144.    Solution: A narrow-band UHF satellite radio FEC prototype was
  145.    developed that improves data reliability, without excessively
  146.    increasing synchronization requirements. The prototype FEC increased
  147.    synchronization requirements by less than 50 milliseconds (ms). The
  148.    FEC implementation will improve an average 10e-3 BER channel to an
  149.    average 10e-5 BER channel.
  150.  
  151. Delays
  152.  
  153.    Including satellite propagation delays, the tactical satellite radios
  154.    require approximately 1.25 seconds for radio synchronization prior to
  155.    transmitting any data across the communication channel.  Therefore,
  156.    limiting the number of channel accesses required will permit data
  157.    throughput to increase. This can be achieved by minimizing the number
  158.    of acknowledgments required during the file transfer.  FTP generates
  159.    many acknowledgments which decreases throughput by increasing the
  160.    number of satellite channel accesses required.
  161.  
  162.    To clarify, when a FTP connection request is generated, it is sent
  163.    via Ethernet to the router and then forwarded to the radio network
  164.    controller (RNC).  The elapsed time is less than 30 ms. The RNC keys
  165.    the crypto unit and 950 ms later modem/crypto synchronization occurs.
  166.    After synchronization is achieved, the FTP connection request is
  167.  
  168.  
  169.  
  170. Polites, Wollman & Woo        Experimental                      [Page 3]
  171.  
  172. RFC 1986                         ETFTP                       August 1996
  173.  
  174.  
  175.    transmitted. The transmitting terminal then drops the channel and the
  176.    modem/crypto synchronization is lost. Assuming that the request was
  177.    received successfully, the receiving host processes the request and
  178.    sends an acknowledgment. Again the modem/crypto have to synchronize
  179.    prior to transmitting the acknowledgment. Propagation delays over a
  180.    UHF satellite also adds roughly 500 ms to the total round trip delay.
  181.  
  182.    Solution: When compared to FTP, NETBLT significantly reduces the
  183.    number of acknowledgments required to complete a file transfer.
  184.    Therefore, leveraging the features available within an implementation
  185.    of NETBLT will significantly improve throughput across the narrow-
  186.    band UHF satellite communication link.
  187.  
  188.    To reduce the number of channel accesses required, a number of AX.25
  189.    parameters were modified.  These included the value of p for use
  190.    within the p-persistence link layer protocol, the slot time, the
  191.    transmit tail time, and the transmit delay time.  The p-persistence
  192.    is a random number threshold between 0 and 255.  The slot time is the
  193.    time to wait prior to attempting to access the channel.  The transmit
  194.    tail increases the amount of time the radio carrier is held on, prior
  195.    to dropping the channel. Transmit delay is normally equal to the
  196.    value of the radio synchronization time.  By adjusting these
  197.    parameters to adapt to the tactical satellite environment, improved
  198.    communication performance can be achieved.
  199.  
  200.    First, in ETFTP, several packets within a buffer are transmitted
  201.    within one burst. If the buffer is partitioned into ten packets, each
  202.    of 1024 bytes, then 10,240 bytes of data is transmitted with each
  203.    channel access. It is possible to configure ETFTP's burstsize to
  204.    equal the number of packets per buffer. Second, the transmit tail
  205.    time was increased to hold the key down on the transmitter long
  206.    enough to insure all of the packets within the buffer are sent in a
  207.    single channel access. These two features, together, allow the system
  208.    to transmit an entire file (example, 100,000 bytes) with only a
  209.    single channel access by adjusting buffer size. Thirdly, the ETFTP
  210.    protocol only acknowledges each buffer, not each packet. Thus, a
  211.    single acknowledgment is sent from the receiving terminal containing
  212.    a request for the missing packets within each buffer, reducing the
  213.    number of acknowledgment packets sent. Which in turn, reduced the
  214.    number of times the channel has to be turned around.
  215.  
  216.    To reduce channel access time, p-persistence was set to the maximum
  217.    value and slot time to a minimum value. These settings support
  218.    operations for a point-to-point communication link between two users.
  219.    This value of p would not be used if more users were sharing the
  220.    satellite channel.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Polites, Wollman & Woo        Experimental                      [Page 4]
  227.  
  228. RFC 1986                         ETFTP                       August 1996
  229.  
  230.  
  231. Backoffs
  232.  
  233.    TCP's slow start and backoff algorithms implemented in most TCP
  234.    packages assume that packet loss is due to network congestion.  When
  235.    operating across a tactical half duplex communication channel
  236.    dedicated to two users, packet loss is primarily due to poor channel
  237.    quality, not network congestion. A linear backoff at the transport
  238.    layer is recommended. In a tactical radio network there are numerous
  239.    cases where a single host is connected to multiple radios. In a
  240.    tactical radio network, layer two will handle channel access.
  241.    Channel access will be adjusted through parameters like p-persistence
  242.    and slot time. The aggregate effect of the exponential backoff from
  243.    the transport layer added to the random backoff of the data link
  244.    layer, will in most cases, cause the radio network to miss many
  245.    network access opportunities. A linear backoff will reduce the number
  246.    missed data link network access opportunities
  247.  
  248.    Solution: Tunable parameters and timers have been modified to
  249.    resemble those suggested by NETBLT.
  250.  
  251. Packet Size
  252.  
  253.    In a tactical environment, channel conditions change rapidly.
  254.    Continuously transmitting large packets under 10e-3 BER conditions
  255.    reduces effective throughput.
  256.  
  257.    Solution: Packet sizes are dynamically adjusted based upon the
  258.    success of the buffer transfers. If 99 percent of all packets within
  259.    a buffer are received successfully, packet size can be increased to a
  260.    negotiated value.  If 50 percent or more of all packets within a
  261.    buffer are not successfully delivered, the packet size can be
  262.    decreased to a negotiated value.
  263.  
  264. 2. PROTOCOL DESCRIPTION
  265.  
  266.    Throughout this document the term packet is used to describe a
  267.    datagram that includes all network overhead. A block is used to
  268.    describe information, without any network encapsulation.
  269.  
  270.    The original source files for TFTP, as downloaded from ftp.uu.net,
  271.    were modified to implement the ETFTP/NETBLT protocol. These same
  272.    files are listed in "UNIX Network Programming" [5].
  273.  
  274.    ETFTP was implemented for operations under the Santa Cruz Operations
  275.    (SCO) UNIX. In the service file, "/etc/services", an addition was
  276.    made to support "etftp" at a temporary well known port of "1818"
  277.    using "UDP" protocol. The file, "/etc/inetd.conf", was modified so
  278.    the "inetd" program could autostart the "etftpd" server when a
  279.  
  280.  
  281.  
  282. Polites, Wollman & Woo        Experimental                      [Page 5]
  283.  
  284. RFC 1986                         ETFTP                       August 1996
  285.  
  286.  
  287.    connection request came in on the well known port.
  288.  
  289.    As stated earlier, the transport layer for ETFTP is UDP, which will
  290.    not be discussed further here. This client server application layer
  291.    protocol is NETBLT, with four notable differences.
  292.  
  293.    The first change is that this NETBLT protocol is implemented on top
  294.    of the UDP layer. This allowed the NETBLT concepts to be tested
  295.    without modifying the operating system's transport or network layers.
  296.    Table 2, "Four Layer Protocol Model," shows the protocol stack for
  297.    FTP, TFTP and ETFTP.
  298.  
  299.    Table 2: Four Layer Protocol Model
  300.  
  301.    +---------------------------------------------------------------+
  302.    |                         PROTOCOL STACK                        |
  303.    +---------------+---------------+---------------+---------------+
  304.    |APPLICATION    |FTP            |TFTP           |ETFTP/NETBLT   |
  305.    +---------------+---------------+---------------+---------------+
  306.    |TRANSPORT      |TCP            |UDP            |UDP            |
  307.    +---------------+---------------+---------------+---------------+
  308.    |NETWORK        |IP                                             |
  309.    +---------------+---------------+---------------+---------------+
  310.    |LINK           |Ethernet, SLIP, AX.25                          |
  311.    +---------------+---------------+---------------+---------------+
  312.  
  313.    The second change is a carryover from TFTP, which allows files to be
  314.    transferred in netascii or binary modes. A new T bit flag is assigned
  315.    to the reserved field of the OPEN message type.
  316.  
  317.    The third change is to re-negotiate the DATA packet size. This change
  318.    affects the OPEN, NULL-ACK, and CONTROL_OK message types.  A new R
  319.    bit is assigned to the reserved field of the OPEN message type.
  320.  
  321.    The fourth change is the addition of two new fields to the OPEN
  322.    message type. The one field is a two byte integer for radio delay in
  323.    seconds, and the next field is two bytes of padding.
  324.  
  325.    The ETFTP data encapsulation is shown in Table 3, "ETFTP Data
  326.    Encapsulation,". The Ethernet, SLIP, and AX.25 headers are mutually
  327.    exclusive. They are stripped off and added by the appropriate
  328.    hardware layer.
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Polites, Wollman & Woo        Experimental                      [Page 6]
  339.  
  340. RFC 1986                         ETFTP                       August 1996
  341.  
  342.  
  343.    Table 3: ETFTP Data Encapsulation
  344.  
  345.    +------------+------------+------------+------------+-----------+
  346.    |Ethernet(14)|            |            |ETFTP/      |           |
  347.    |SLIP(2)     |IP(20)      |UDP(8)      |NETBLT(24)  |DATA(1448) |
  348.    |AX.25(20)   |            |            |            |           |
  349.    +------------+------------+------------+------------+-----------+
  350.  
  351. 2.1     MESSAGE TYPES AND FORMATS
  352.  
  353.    Here are the ETFTP/NETBLT message types and formats.
  354.  
  355.    MESSAGES        VALUES
  356.    OPEN    0  Client request to open a new connection
  357.    RESPONSE        1  Server positive acknowledgment for OPEN
  358.    KEEPALIVE       2  Reset the timer
  359.    QUIT    3  Sender normal Close request
  360.    QUITACK 4  Receiver acknowledgment of QUIT
  361.    ABORT   5  Abnormal close
  362.    DATA    6  Sender packet containing data
  363.    LDATA   7  Sender last data block of a buffer
  364.    NULL-ACK        8  Sender confirmation of CONTROL_OK changes
  365.    CONTROL 9  Receiver request to
  366.            GO      0 Start transmit of next buffer
  367.            OK      1 Acknowledge complete buffer
  368.            RESEND  2 Retransmit request
  369.    REFUSED 10 Server negative acknowledgment of OPEN
  370.    DONE    11 Receiver acknowledgment of QUIT.
  371.  
  372.    Packets are "longword-aligned", at four byte word boundaries.
  373.    Variable length strings are NULL terminated, and padded to the four
  374.    byte boundary. Fields are listed in network byte order. All the
  375.    message types share a common 12 byte header. The common fields are:
  376.  
  377.    Checksum        IP compliant checksum
  378.    Version Current version ID
  379.    Type    NETBLT message type
  380.    Length  Total byte length of packet
  381.    Local Port      My port ID
  382.    Foreign Port    Remote port ID
  383.    Padding Pad as necessary to 4 byte boundary
  384.  
  385.    The OPEN and RESPONSE messages are similar and shown in Table 4,
  386.    "OPEN and RESPONSE Message Types,". The client string field is used
  387.    to carry the filename to be transferred.
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Polites, Wollman & Woo        Experimental                      [Page 7]
  395.  
  396. RFC 1986                         ETFTP                       August 1996
  397.  
  398.  
  399.    Table 4: OPEN and RESPONSE Message Types
  400.  
  401.                       1                   2                   3
  402.     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
  403.    +---------------+---------------+---------------+---------------+
  404.    |Checksum                       |Version        |Type           |
  405.    +---------------+---------------+---------------+---------------+
  406.    |Length                         |Local Port                     |
  407.    +---------------+---------------+---------------+---------------+
  408.    |Foreign Port                   |Longword Alignment Padding     |
  409.    +---------------+---------------+---------------+---------------+
  410.    |Connection ID                                                  |
  411.    +---------------+---------------+---------------+---------------+
  412.    |Buffer size                                                     |
  413.    +---------------+---------------+---------------+---------------+
  414.    |Transfer size                                                   |
  415.    +---------------+---------------+---------------+---------------+
  416.    |DATA Packet size                |Burstsize                      |
  417.    +---------------+---------------+---------------+---------------+
  418.    |Burstrate                      |Death Timer Value              |
  419.    +---------------+---------------+---------------+---------------+
  420.    |Reserved(MBZ)          |R|T|C|M|Maximum # Outstanding Buffers  |
  421.    +---------------+---------------+---------------+---------------+
  422.    |*Radio Delay                   |*Padding                       |
  423.    +---------------+---------------+---------------+---------------+
  424.    |Client String . . .            |Longword Alignment Padding     |
  425.    +---------------+---------------+---------------+---------------+
  426.  
  427.    Connection ID   The unique connection number
  428.    Buffer size     Bytes per buffer
  429.    Transfer size   The length of the file in bytes
  430.    DATA Packet size        Bytes per ETFTP block
  431.    Burstsize       Concatenated packets per burst
  432.    Burstrate       Milliseconds per burst
  433.    Death Timer     Seconds before closing idle links
  434.    Reserved        M bit is mode: 0=read/put, 1=write/get
  435.            C bit is checksum: 0=header, 1=all
  436.            *T bit is transfer: 0=netascii, 1=binary
  437.            *R bit is re-negotiate: 0=off, 1=on
  438.    Max # Out Buffs Maximum allowed un-acknowledged buffers
  439.    Radio Delay     *Seconds of delay from send to receive
  440.    Padding *Unused
  441.    Client String   Filename.
  442.  
  443.    The KEEPALIVE, QUITACK, and DONE messages are identical to the common
  444.    header, except for the message type values. See Table 5, "KEEPALIVE,
  445.    QUITACK, and DONE Message Types,".
  446.  
  447.  
  448.  
  449.  
  450. Polites, Wollman & Woo        Experimental                      [Page 8]
  451.  
  452. RFC 1986                         ETFTP                       August 1996
  453.  
  454.  
  455.    Table 5: KEEPALIVE, QUITACK, and DONE Message Types
  456.  
  457.                       1                   2                   3
  458.     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
  459.    +---------------+---------------+---------------+---------------+
  460.    |Checksum                       |Version        |Type           |
  461.    +---------------+---------------+---------------+---------------+
  462.    |Length                         |Local Port                     |
  463.    +---------------+---------------+---------------+---------------+
  464.    |Foreign Port                   |Longword Alignment Padding     |
  465.    +---------------+---------------+---------------+---------------+
  466.  
  467.  
  468.    The QUIT, ABORT, and REFUSED messages allow a string field to carry
  469.    the reason for the message. See Table 6, "QUIT, ABORT, and REFUSED
  470.    Message Types,".
  471.  
  472.    Table 6: QUIT, ABORT, and REFUSED Message Types
  473.  
  474.                       1                   2                   3
  475.     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
  476.    +---------------+---------------+---------------+---------------+
  477.    |Checksum                       |Version        |Type           |
  478.    +---------------+---------------+---------------+---------------+
  479.    |Length                         |Local Port                     |
  480.    +---------------+---------------+---------------+---------------+
  481.    |Foreign Port                   |Longword Alignment Padding     |
  482.    +---------------+---------------+---------------+---------------+
  483.    |Reason for QUIT/ABORT/REFUSED . . .                            |
  484.    +---------------+---------------+---------------+---------------+
  485.    |. . .                          |Longword Alignment Padding     |
  486.    +---------------+---------------+---------------+---------------+
  487.  
  488.    The DATA and LDATA messages make up the bulk of the messages
  489.    transferred. The last packet of each buffer is flagged as an LDATA
  490.    message. Each and every packet of the last buffer has the reserved L
  491.    bit set. The highest consecutive sequence number is used for the
  492.    acknowledgment of CONTROL messages. It should contain the ID number
  493.    of the current CONTROL message being processed. Table 7, "DATA and
  494.    LDATA Message Types,", shows the DATA and LDATA formats.
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Polites, Wollman & Woo        Experimental                      [Page 9]
  507.  
  508. RFC 1986                         ETFTP                       August 1996
  509.  
  510.  
  511.    Table 7: DATA and LDATA Message Types
  512.  
  513.                       1                   2                   3
  514.     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
  515.    +---------------+---------------+---------------+---------------+
  516.    |Checksum                       |Version        |Type           |
  517.    +---------------+---------------+---------------+---------------+
  518.    |Length                         |Local Port                     |
  519.    +---------------+---------------+---------------+---------------+
  520.    |Foreign Port                   |Longword Alignment Padding     |
  521.    +---------------+---------------+---------------+---------------+
  522.    |Buffer Number                                                  |
  523.    +---------------+---------------+---------------+---------------+
  524.    |High Consecutive Seq Num Rcvd  |Packet Number                  |
  525.    +---------------+---------------+---------------+---------------+
  526.    |Data Area Checksum Value       |Reserved (MBZ)               |L|
  527.    +---------------+---------------+---------------+---------------+
  528.  
  529.    Buffer Number   The first buffer number starts at 0
  530.    Hi Con Seq Num  The acknowledgment for CONTROL messages
  531.    Packet Number   The first packet number starts at 0
  532.    Data Checksum   Checksum for data area only
  533.    Reserved        L: the last buffer bit: 0=false, 1=true
  534.  
  535.    The NULL-ACK message type is sent as a response to a CONTROL_OK
  536.    message that modifies the current packet size, burstsize, or
  537.    burstrate. In acknowledging the CONTROL_OK message, the sender is
  538.    confirming the change request to the new packet size, burstsize, or
  539.    burstrate. If no modifications are requested, a NULL-ACK message is
  540.    unnecessary. See Table 8, "NULL-ACK Message Type," for further
  541.    details.
  542.  
  543.    Table 8: NULL-ACK Message Type
  544.  
  545.                       1                   2                   3
  546.     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
  547.    +---------------+---------------+---------------+---------------+
  548.    |Checksum                       |Version        |Type           |
  549.    +---------------+---------------+---------------+---------------+
  550.    |Length                         |Local Port                     |
  551.    +---------------+---------------+---------------+---------------+
  552.    |Foreign Port                   |Longword Alignment Padding     |
  553.    +---------------+---------------+---------------+---------------+
  554.    |High Consecutive Seq Num Rcvd  |New Burstsize                  |
  555.    +---------------+---------------+---------------+---------------+
  556.    |New Burstrate                  |*New DATA Packet size           |
  557.    +---------------+---------------+---------------+---------------+
  558.  
  559.  
  560.  
  561.  
  562. Polites, Wollman & Woo        Experimental                     [Page 10]
  563.  
  564. RFC 1986                         ETFTP                       August 1996
  565.  
  566.  
  567.    The CONTROL messages have three subtypes: GO, OK, and RESEND as shown
  568.    in Tables 9-12. The CONTROL message common header may be followed by
  569.    any number of longword aligned subtype messages.
  570.  
  571.    Table 9: CONTROL Message Common Header
  572.  
  573.                       1                   2                   3
  574.     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
  575.    +---------------+---------------+---------------+---------------+
  576.    |Checksum                       |Version        |Type           |
  577.    +---------------+---------------+---------------+---------------+
  578.    |Length                         |Local Port                     |
  579.    +---------------+---------------+---------------+---------------+
  580.    |Foreign Port                   |Longword Alignment Padding     |
  581.    +---------------+---------------+---------------+---------------+
  582.  
  583.    Table 10: CONTROL_GO Message Subtype
  584.  
  585.                       1                   2                   3
  586.     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
  587.    +---------------+---------------+---------------+---------------+
  588.    |Subtype        |Padding        |Sequence Number                |
  589.    +---------------+---------------+---------------+---------------+
  590.    |Buffer Number                                                  |
  591.    +---------------+---------------+---------------+---------------+
  592.  
  593.    Table 11: CONTROL_OK Message Subtype
  594.  
  595.                      1                   2                   3
  596.     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
  597.    +---------------+---------------+---------------+---------------+
  598.    |Subtype        |Padding        |Sequence Number                |
  599.    +---------------+---------------+---------------+---------------+
  600.    |Buffer Number                                                  |
  601.    +---------------+---------------+---------------+---------------+
  602.    |New Offered Burstsize          |New Offered Burstrate          |
  603.    +---------------+---------------+---------------+---------------+
  604.    |Current Control Timer Value    |*New DATA Packet size           |
  605.    +---------------+---------------+---------------+---------------+
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Polites, Wollman & Woo        Experimental                     [Page 11]
  619.  
  620. RFC 1986                         ETFTP                       August 1996
  621.  
  622.  
  623.    Table 12: CONTROL_RESEND Message Subtype
  624.  
  625.                       1                   2                   3
  626.     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
  627.    +---------------+---------------+---------------+---------------+
  628.    |Subtype        |Padding        |Sequence Number                |
  629.    +---------------+---------------+---------------+---------------+
  630.    |Buffer Number                                                  |
  631.    +---------------+---------------+---------------+---------------+
  632.    |Number of Missing Packets      |Longword Alignment Padding     |
  633.    +---------------+---------------+---------------+---------------+
  634.    |Packet Number (2 bytes)        |. . .                          |
  635.    +---------------+---------------+---------------+---------------+
  636.    |. . .                          |Longword Alignment Padding     |
  637.    +---------------+---------------+---------------+---------------+
  638.  
  639. 2.2 ETFTP COMMAND SET
  640.  
  641.    Being built from TFTP source code, ETFTP shares a significant portion
  642.    of TFTP's design. Like TFTP, ETFTP does NOT support user password
  643.    validation. The program does not support changing directories (i.e.
  644.    cd), neither can it list directories, (i.e. ls). All filenames must
  645.    be given in full paths, as relative paths are not supported. The
  646.    internal finite state machine was modified to support NETBLT message
  647.    types.
  648.  
  649.    The NETBLT protocol is implemented as closely as possible to what is
  650.    described in RFC 998, with a few exceptions. The client string field
  651.    in the OPEN message type is used to carry the filename of the file to
  652.    be transferred. Netascii or binary transfers are both supported. If
  653.    enabled, new packet sizes, burstsizes, and burstrates are re-
  654.    negotiated downwards when half or more of the blocks in a buffer
  655.    require retransmission. If 99% of the packets in a buffer is
  656.    successfully transferred without any retransmissions, packet size is
  657.    re-negotiated upwards.
  658.  
  659.    The interactive commands supported by the client process are similar
  660.    to TFTP. Here is the ETFTP command set. Optional parameters are in
  661.    square brackets. Presets are in parentheses.
  662.  
  663.    ?       help, displays command list
  664.    ascii   mode ascii, appends CR-LF per line
  665.    autoadapt       toggles backoff function (on)
  666.    baudrate baud   baud rate (16000 bits/sec)
  667.    binary  mode binary, image transfer
  668.    blocksize bytes packet size in bytes (512 bytes/block)
  669.    bufferblock blks        buffer size in blocks (128 blocks/buff)
  670.    burstsize packets       burst size in packets (8 blocks/burst)
  671.  
  672.  
  673.  
  674. Polites, Wollman & Woo        Experimental                     [Page 12]
  675.  
  676. RFC 1986                         ETFTP                       August 1996
  677.  
  678.  
  679.    connect host [p]        establish connection with host at port p
  680.    exit    ends program
  681.    get rfile lfile copy remote file to local file
  682.    help    same as ?
  683.    mode choice     set transfer mode (binary)
  684.    multibuff num   number of buffers (2 buffers)
  685.    put lfile rfile copy local file to remote file
  686.    quit    same as exit
  687.    radiodelay sec  transmission delay in seconds (2 sec)
  688.    status  display network parameters
  689.    trace   toggles debug display (off).
  690.  
  691. 2.3 DATA TRANSFER AND FLOW CONTROL
  692.  
  693.    This is the scenario between client and server transfers:
  694.  
  695.    Client sends OPEN for connection, blocksize, buffersize, burstsize,
  696.    burstrate, transfer mode, and get or put. See M bit of reserved
  697.    field.
  698.  
  699.    Server sends a RESPONSE with the agreed parameters.
  700.  
  701.    Receiver sends a CONTROL_GO request sending of first buffer.
  702.  
  703.    Sender starts transfer by reading the file into multiple memory
  704.    buffers. See Figure 1, "File Segmentation,". Each buffer is divided
  705.    according to the number of bytes/block. Each block becomes a DATA
  706.    packet, which is concatenated according to the blocks/burst.  Bursts
  707.    are transmitted according to the burstrate. Last data block is
  708.    flagged as LDATA type.
  709.  
  710.    +---+     +---+      +---+ +---+ +---+      +---+ +---+ +---+
  711.    |   |     | 0 |      | L | | 4 | | 3 | ---- | 2 | | 1 | | 0 |
  712.    |   |     | +---+    +---+ +---+ +---+      +---+ +---+ +---+
  713.    |   |     +-|   | -->      +---+ +---+      +---+ +---+ +---+
  714.    |   | -->   | 1 |          | L | | 3 | ---- | 2 | | 1 | | 0 |
  715.    +---+       +---+          +---+ +---+      +---+ +---+ +---+
  716.    File   Multi Buffers  Blocks per Burst
  717.  
  718.    Figure 1. File Segmentation
  719.  
  720.    Receiver acknowledges buffer as CONTROL_OK or CONTROL_RESEND.
  721.  
  722.    If blocks are missing, a CONTROL_RESEND packet is transmitted. If
  723.    half or more of the blocks in a buffer are missing, an adaptive
  724.    algorithm is used for the next buffer transfer. If no blocks are
  725.    missing, a CONTROL_OK packet is transmitted.
  726.  
  727.  
  728.  
  729.  
  730. Polites, Wollman & Woo        Experimental                     [Page 13]
  731.  
  732. RFC 1986                         ETFTP                       August 1996
  733.  
  734.  
  735.    Sender re-transmits blocks until receipt of a CONTROL_OK. If the
  736.    adaptive algorithm is set, then new parameters are offered, in the
  737.    CONTROL_OK message. The priority of the adaptive algorithm is:
  738.  
  739.    -       Reduce packetsize by half (MIN = 16 bytes/packet)
  740.    -       Reduce burstsize by one (MIN = 1 packet/burst)
  741.    -       Reduce burstrate to actual tighttimer rate
  742.  
  743.    If new parameters are valid, the sender transmits a NULL-ACK packet,
  744.    to confirm the changes.
  745.  
  746.    Receiver sends a CONTROL_GO to request sending next buffer.
  747.  
  748.    At end of transfer, sender sends a QUIT to close the connection.
  749.  
  750.    Receiver acknowledges the close request with a DONE packet.
  751.  
  752. 2.4 TUNABLE PARAMETERS
  753.  
  754.    These parameters directly affect the throughput rate of ETFTP.
  755.  
  756.    Packetsize      The packetsize is the number of 8 bit bytes per
  757.    packet. This number refers to the user data bytes in a block, (frame),
  758.    exclusive of any network overhead. The packet size has a valid range
  759.    from 16 to 1,448 bytes. The Maximum Transfer Unit (MTU) implemented in
  760.    most commercial network devices is 1,500 bytes. The de-facto industry
  761.    standard is 576 byte packets.
  762.  
  763.    Bufferblock     The bufferblock is the number of blocks per buffer.
  764.    Each implementation may have restrictions on available memory, so the
  765.    buffersize is calculated by multiplying the packetsize times the
  766.    bufferblocks.
  767.  
  768.    Baudrate        The baudrate is the bits per second transfer rate of
  769.    the slowest link (i.e., the radios). The baudrate sets the speed of
  770.    the sending process. The sending process cannot detect the actual
  771.    speed of the network, so the user must set the correct baudrate.
  772.  
  773.    Burstsize       The burstsize in packets per burst sets how many
  774.    packets are concatenated and burst for transmission efficiency. The
  775.    burstsize times the packetsize must not exceed the available memory of
  776.    any intervening network devices. On the Ethernet portion of the
  777.    network, all the packets are sent almost instantaneously. It is
  778.    necessary to wait for the network to drain down its memory buffers,
  779.    before the next burst is sent. The sending process needs to regulate
  780.    the rate used to place packets into the network.
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Polites, Wollman & Woo        Experimental                     [Page 14]
  787.  
  788. RFC 1986                         ETFTP                       August 1996
  789.  
  790.  
  791.    Radiodelay      The radiodelay is the time in seconds per burst it
  792.    takes to synchronize with the radio controllers. Any additional
  793.    hardware delays should be set here. It is the aggregate delay of the
  794.    link layer, such as transmitter key-up, FEC, crypto synchronization,
  795.    and propagation delays.
  796.  
  797.    These parameters above are used to calculate a burstrate, which is the
  798.    length of time it takes to transmit one burst. The ov is the overhead
  799.    of 72 bytes per packet of network encapsulation. A byte is defined as
  800.    8 bits. The burstrate value is:
  801.  
  802.      burstrate = (packetsize+ov)*burstsize*8/baudrate
  803.  
  804.    In a effort to calculate the round trip time, when data is flowing in
  805.    one direction for most of the transfer, the OPEN and RESPONSE message
  806.    types are timed, and the tactical radio delays are estimated. Using
  807.    only one packet in each direction to estimate the rate of the link is
  808.    statistically inaccurate. It was decided that the radio delay should
  809.    be a constant provided by the user interface.  However, a default
  810.    value of 2 seconds is used. The granularity of this value is in
  811.    seconds because of two reasons. The first reason is that the UNIX
  812.    supports a sleep function in seconds only. The second reason is that
  813.    in certain applications, such as deep space probes, a 16-bit integer
  814.    maximum of 32,767 seconds would suffice.
  815.  
  816. 2.5 DELAYS AND TIMERS
  817.  
  818.    From these parameters, several timers are derived. The control timer
  819.    is responsible for measuring the per buffer rate of transfer. The
  820.    SENDER copy is nicknamed the loosetimer.
  821.  
  822.      loosetimer = (burstrate+radiodelay)*bufferblock/burstsize
  823.  
  824.    The RECEIVER copy of the timer is nicknamed the tighttimer, which
  825.    measures the elapsed time between CONTROL_GO and CONTROL_OK packets.
  826.    The tighttimer is returned to the SENDER to allow the protocol to
  827.    adjust for the speed of the network.
  828.  
  829.    The retransmit timer is responsible for measuring the network receive
  830.    data function. It is used to set an alarm signal (SIGALRM) to
  831.    interrupt the network read. The retransmit timer (wait) is initially
  832.    set to be the greater of twice the round trip or 4 times the
  833.    radiodelay, plus a constant 5 seconds.
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Polites, Wollman & Woo        Experimental                     [Page 15]
  843.  
  844. RFC 1986                         ETFTP                       August 1996
  845.  
  846.  
  847.       wait = MAX ( 2*roundtriptime,  4*radiodelay ) + 5 seconds
  848.  
  849.    and
  850.  
  851.       alarm timeout = wait.
  852.  
  853.    Each time the same read times out, a five second backoff is added to
  854.    the next wait. The backoff is necessary because the initial user
  855.    supplied radiodelay, or the initial measured round trip time may be
  856.    incorrect.
  857.  
  858.    The retransmit timer is set differently for the RECEIVER during a
  859.    buffer transfer. Before the arrival of the first DATA packet, the
  860.    original alarm time out is used. Once the DATA packets start
  861.    arriving, and for the duration of each buffer transfer, the RECEIVER
  862.    alarm time out is reset to the expected arrival time of the last DATA
  863.    packet (blockstogo) plus the delay (wait). As each DATA packet is
  864.    received, the alarm is decremented by one packet interval. This same
  865.    algorithm is used for receiving missing packets, during a RESEND.
  866.  
  867.      alarmtimeout = blockstogo*burstrate/burstsize + wait
  868.  
  869.    The death timer is responsible for measuring the idle time of a
  870.    connection. In the ETFTP program, the death timer is set to be equal
  871.    to the accumulated time of ten re-transmissions plus their associated
  872.    backoffs. As such, the death timer value in the OPEN and RESPONSE
  873.    message types is un-necessary. In the ETFTP program, this field could
  874.    be used to transfer the radio delay value instead of creating the two
  875.    new fields.
  876.  
  877.    The keepalive timer is responsible for resetting the death timer.
  878.    This timer will trigger the sending of a KEEPALIVE packet to prevent
  879.    the remote host from closing a connection due to the expiration of
  880.    its death timer. Due to the nature of the ETFTP server process, a
  881.    keepalive timer was not necessary, although it is implemented.
  882.  
  883. 2.6 TEST RESULTS
  884.  
  885.    The NETBLT protocol has been tested on other high speed networks
  886.    before, see RFC 1030 [6]. These test results in Tables 13 and 14,
  887.    "ETFTP Performance," were gathered from files transferred across the
  888.    network and LST-5C TACSAT radios.  The radios were connected together
  889.    via a coaxial cable to provide a "clean" link. A clean link is
  890.    defined to a BER of 10e-5. The throughput rates are defined to be the
  891.    file size divided by the elapsed time resulting in bits per second
  892.    (bps).  The elapsed time is measured from the time of the "get" or
  893.    "put" command to the completion of the transfer. This is an all
  894.    inclusive time measurement based on user perspective. It includes the
  895.  
  896.  
  897.  
  898. Polites, Wollman & Woo        Experimental                     [Page 16]
  899.  
  900. RFC 1986                         ETFTP                       August 1996
  901.  
  902.  
  903.    connection time, transfer time, error recovery time, and disconnect
  904.    time. The user concept of elapsed time is the length of time it takes
  905.    to copy a file from disk to disk. These results show only the average
  906.    performances, including the occasional packet re-transmissions. The
  907.    network configuration was set as:
  908.  
  909.    ETFTP Parameters:
  910.  
  911.    Filesize                101,306 bytes
  912.    Radiodelay      2 seconds
  913.    Buffersize      16,384-131,072 bytes
  914.    Packetsize      512-2048 bytes
  915.    Burstsize               8-16 packets/burst
  916.  
  917.    Gracilis PackeTen Parameters:
  918.  
  919.    0 TX Delay      400 milliseconds
  920.    1 P Persist     255 [range 1-255]
  921.    2 Slot Time     30 milliseconds
  922.    3 TX Tail               300 milliseconds
  923.    4 Rcv Buffers   8 2048 bytes/buffer
  924.    5 Idle Code     Flag
  925.  
  926.    Radio Parameters:
  927.  
  928.    Baudrate                16,000 bps
  929.    Encryption      on
  930.  
  931.  
  932.    Table 13: ETFTP Performance at 8 Packets/Burst in Bits/Second
  933.  
  934.    +-----------+-----------+-----------+-----------+-----------+
  935.    |buffersize |packetsize |packetsize |packetsize |packetsize |
  936.    |(bytes)    |2,048 bytes|1,448 bytes|1,024 bytes|512 bytes  |
  937.    +-----------+-----------+-----------+-----------+-----------+
  938.    |    16,384 |     7,153 |     6,952 |     6,648 |     5,248 |
  939.    +-----------+-----------+-----------+-----------+-----------+
  940.    |    32,768 |     7,652 |     7,438 |     7,152 |     4,926 |
  941.    +-----------+-----------+-----------+-----------+-----------+
  942.    |    65,536 |     8,072 |     8,752 |     8,416 |     5,368 |
  943.    +-----------+-----------+-----------+-----------+-----------+
  944.    |   131,072 |     8,828 |     9,112 |     7,888 |     5,728 |
  945.    +-----------+-----------+-----------+-----------+-----------+
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Polites, Wollman & Woo        Experimental                     [Page 17]
  955.  
  956. RFC 1986                         ETFTP                       August 1996
  957.  
  958.  
  959.    Table 14: ETFTP Performance at 16 Packets/Burst in Bits/Second
  960.  
  961.    +-----------+-----------+-----------+-----------+-----------+
  962.    |buffersize |packetsize |packetsize |packetsize |packetsize |
  963.    |(bytes)    |2,048 bytes|1,448 bytes|1,024 bytes|512 bytes  |
  964.    +-----------+-----------+-----------+-----------+-----------+
  965.    |    16,384 |     5,544 |     5,045 |     4,801 |     4,570 |
  966.    +-----------+-----------+-----------+-----------+-----------+
  967.    |    32,768 |     8,861 |     8,230 |     8,016 |     7,645 |
  968.    +-----------+-----------+-----------+-----------+-----------+
  969.    |    65,536 |     9,672 |     9,424 |     9,376 |     8,920 |
  970.    +-----------+-----------+-----------+-----------+-----------+
  971.    |   131,072 |    10,432 |    10,168 |     9,578 |     9,124 |
  972.    +-----------+-----------+-----------+-----------+-----------+
  973.  
  974. 2.7 PERFORMANCE CONSIDERATIONS
  975.  
  976.    These tests were performed across a tactical radio link with a
  977.    maximum data rate of 16000 bps. In testing ETFTP, it was found that
  978.    the delay associated with the half duplex channel turnaround time was
  979.    the biggest factor in throughput performance. Therefore, every
  980.    attempt was made to minimize the number of times the channel needed
  981.    to be turned around. Obviously, the easiest thing to do is to use as
  982.    big a buffer as necessary to read in a file, as acknowledgments
  983.    occurred only at the buffer boundaries. This is not always feasible,
  984.    as available storage on disk could easily exceed available memory.
  985.    However, the current ETFTP buffersize is set at a maximum of 524,288
  986.    bytes.
  987.  
  988.    The larger packetsizes also improved performance. The limit on
  989.    packetsize is based on the 1500 byte MTU of network store and forward
  990.    devices. In a high BER environment, a large packetsize could be
  991.    detrimental to success. By reducing the packetsize, even though it
  992.    negatively impacts performance, reliability is sustained. When used
  993.    in conjunction with FEC, both performance and reliability can be
  994.    maintained at an acceptable level.
  995.  
  996.    The burstsize translates into how long the radio transmitters are
  997.    keyed to transmit. In ETFTP, the ideal situation is to have the first
  998.    packet of a burst arrive in the radio transmit buffer, as the last
  999.    packet of the previous burst is just finished being sent. In this
  1000.    way, the radio transmitter would never be dropped for the duration of
  1001.    one buffer. In a multi-user radio network, a full buffer transmission
  1002.    would be inconsiderate, as the transmit cycle could last for several
  1003.    minutes, instead of seconds. In measuring voice communications,
  1004.    typical transmit durations are on the order of five to twenty
  1005.    seconds.  This means that the buffersize and burstsize could be
  1006.    adjusted to have similar transmission durations.
  1007.  
  1008.  
  1009.  
  1010. Polites, Wollman & Woo        Experimental                     [Page 18]
  1011.  
  1012. RFC 1986                         ETFTP                       August 1996
  1013.  
  1014.  
  1015. 3.  REFERENCE SECTION
  1016.  
  1017.    [1] Clark, D., Lambert, M., and L. Zhang,
  1018.        "NETBLT: A Bulk Data Transfer Protocol", RFC 998, MIT,
  1019.        March 1987.
  1020.  
  1021.    [2] Postel, J., "User Datagram Protocol" STD 6, RFC 768,
  1022.        USC/Information Sciences Institute, August 1980.
  1023.  
  1024.    [3] Sollins, K., "Trivial File Transfer Protocol", STD 33,
  1025.        RFC 1350, MIT, July 1992.
  1026.  
  1027.    [4] MIL-STD-2045-44500, 18 June 1993, "Military Standard Tactical
  1028.        Communications Protocol 2 (TACO 2) fot the National Imagery
  1029.        Transmission Format Standard", Ft. Monmouth, New Jersey.
  1030.  
  1031.    [5] Stevens, W. Richard, 1990, "UNIX Network Programming",
  1032.        Prentice-Hall Inc., Englewood, New Jersey, Chapter 12.
  1033.  
  1034.    [6] Lambert, M., "On Testing the NETBLT Protocol over
  1035.        Divers Networks", RFC 1030, MIT, November 1987.
  1036.  
  1037. 4.  SECURITY CONSIDERATIONS
  1038.  
  1039.    The ETFTP program is a security loophole in any UNIX environment.
  1040.    There is no user/password validation. All the problems associated to
  1041.    TFTP are repeated in ETFTP. The server program must be owned by root
  1042.    and setuid to root in order to work. As an experimental prototype
  1043.    program, the security issue was overlooked. Since this protocol has
  1044.    proven too be a viable solution in tactical radio networks, the
  1045.    security issues will have to be addressed, and corrected.
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Polites, Wollman & Woo        Experimental                     [Page 19]
  1067.  
  1068. RFC 1986                         ETFTP                       August 1996
  1069.  
  1070.  
  1071. 5.  AUTHORS' ADDRESSES
  1072.  
  1073.    William J. Polites
  1074.    The Mitre Corporation
  1075.    145 Wyckoff Rd.
  1076.    Eatontown, NJ 07724
  1077.  
  1078.    Phone: (908) 544-1414
  1079.    EMail:wpolites@mitre.org
  1080.  
  1081.  
  1082.    William Wollman
  1083.    The Mitre Corporation
  1084.    145 Wyckoff Rd.
  1085.    Eatontown, NJ 07724
  1086.  
  1087.    Phone: (908) 544-1414
  1088.    EMail:wwollman@mitre.org
  1089.  
  1090.  
  1091.    David Woo
  1092.    The Mitre Corporation
  1093.    145 Wyckoff Rd.
  1094.    Eatontown, NJ 07724
  1095.  
  1096.    Phone: (908) 544-1414
  1097.    EMail: dwoo@mitre.org
  1098.  
  1099.  
  1100.    Russ Langan
  1101.    U.S. Army Communications Electronics Command (CECOM)
  1102.    AMSEL-RD-ST-SP
  1103.    ATTN: Russell Langan
  1104.    Fort Monmouth, NJ 07703
  1105.  
  1106.    Phone: (908) 427-2064
  1107.    Fax: (908) 427-2822
  1108.    EMail: langanr@doim6.monmouth.army.mil
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Polites, Wollman & Woo        Experimental                     [Page 20]
  1123.  
  1124. RFC 1986                         ETFTP                       August 1996
  1125.  
  1126.  
  1127. 6.  GLOSSARY
  1128.  
  1129.    ATD             Advanced Technology Demonstration
  1130.    AX.25           Amateur Radio X.25 Protocol
  1131.    BER             Bit Error Rate
  1132.    EPLRS           Enhanced Position Location Reporting Systems
  1133.    ETFTP           Enhanced Trivial File Transfer Protocol
  1134.    FEC             Forward Error Correction
  1135.    FTP             File Transfer Protocol
  1136.    HF              High Frequency
  1137.    LCU             Lightweight Computer Unit
  1138.    ms              milliseconds
  1139.    MTU             Maximum Transfer Unit
  1140.    NETBLT  NETwork Block Transfer protocol
  1141.    NITFS           National Imagery Transmission Format Standard
  1142.    PC              Personal Computer
  1143.    RNC             Radio Network Controller
  1144.    SAS             Survivable Adaptive Systems
  1145.    SATCOM  SATellite COMmunications
  1146.    SCO             Santa Cruz Operations
  1147.    SINCGARS        SINgle Channel Ground and Airborne Radio Systems
  1148.    SLIP            Serial Line Internet Protocol
  1149.    TACO2           Tactical Communications Protocol 2
  1150.    TCP             Transmission Control Protocol
  1151.    TFTP            Trivial File Transfer Protocol
  1152.    UDP             User Datagram Protocol
  1153.    UHF             Ultra High Frequency
  1154.  
  1155.    * Modification from NETBLT RFC 998.
  1156.    * The new packet size is a modification to the NETBLT RFC 998.
  1157.    * The new packet size is a modification to the NETBLT RFC 998.
  1158.  
  1159.  
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Polites, Wollman & Woo        Experimental                     [Page 21]
  1179.  
  1180.