rfc1986.txt

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

   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                                                  |