rfc171.txt

RFC 的详细文档！

Network Working Group                                      Abhay Bhushan
Request for Comments: 171                                            MIT
NIC 6793                                                      Bob Braden
Categories: D.4, D.5, and D.7                                       UCLA
Updates: 114                                               Will Crowther
Obsolete: None                                             Alex McKenzie
                                                                     BBN
                                                            Eric Harslem
                                                            John Heafner
                                                                    Rand
                                                             John Melvin
                                                             Dick Watson
                                                                     SRI
                                                            Bob Sundberg
                                                                 HARVARD
                                                               Jim White
                                                                    UCSB
                                                            23 June 1971

                       THE DATA TRANSFER PROTOCOL

I. INTRODUCTION

   A common protocol is desirable for data transfer in such diverse
   applications as remote job entry, file transfer, network mail system,
   graphics, remote program execution, and communication with block data
   terminals (such as printers, card, paper tape, and magnetic tape
   equipment, especially in context of terminal IMPs).  Although it
   would be possible to include some or even all of the above
   applications in an all-inclusive file transfer protocol, a separation
   between data transfer and application functions would provide
   flexibility in implementation, and reduce complexity.  Separating the
   data transfer function would also reduce proliferation of programs
   and protocols.

   We have therefore defined a low-level data transfer protocol (DTP) to
   be used for transfer of data in file transfer, remote job entry, and
   other applications protocols.  This paper concerns itself solely with
   the data transfer protocol.  A companion paper (RFC 172) describes
   file transfer protocol.

II. DISCUSSION

   The data transfer protocol (DTP) serves three basic functions.  It
   provides for convenient separation of NCP messages into "logical"
   blocks (transactions, units, records, groups, and files), it allows
   for the separation of data and control information, and it includes
   some error control mechanisms.



Bhushan, et al.                                                 [Page 1]

RFC 171                THE DATA TRANSFER PROTOCOL              June 1971


   Three modes of separating messages into transactions [1] are allowed
   by DTP.  The first is an indefinite bit stream which terminates only
   when the connection is closed (i.e., the bit stream represents a
   single transaction for duration of connection).  This mode would be
   useful in data transfer between hosts and terminal IMPs (TIPs).

   The second mode utilizes a "transparent" block convention, similar to
   the ASCII DLE (Data Link Escape).  In "transparent" mode,
   transactions (which may be arbitrarily long) end whenever the
   character sequence DLE ETX is encountered (DLE and ETX are 8-bit
   character codes).  To prevent the possibility of a DLE ETX sequence
   occurring within data stream, any occurrence of DLE is replaced by
   DLE DLE on transmission.  The extra DLE is stripped on reception.  A
   departure from the ASCII convention is that "transparent" block does
   not begin with DLE STX, but with a transaction type byte.  This mode
   will be useful in data transfer between terminal IMPs.

   The third mode utilizes a count mechanism.  Each transaction begins
   with a fixed-length descriptor field containing separate binary
   counts of information bits and filler bits.  If a transaction has no
   filler bits, its filler count is zero.  This mode will be useful in
   most host-to-host data transfer applications.

   DTP allows for the above modes to be intermixed over the same
   connection (i.e., mode is not associated with connection, but only
   with transaction).  The above transfer modes can represent transfer
   of either data or control information.  The protocol allows for
   separating data or control information at a lower level, by providing
   different "type" codes (see SPECIFICATIONS) for data and control
   transactions.  This provision may simplify some implementations.

   The implementation of a workable [2] subset of the above modes is
   specifically permitted by DTP.  To provide compatibility between
   hosts using different subsets of transfer modes, an initial
   "handshake" procedure is required by DTP.  The handshake involves
   exchanging information on modes available for transmit and receive.
   This will enable host programs to agree on transfer modes acceptable
   for a connection.

   The manner in which DTP is used would depend largely on the
   applications protocol.  It is the applications protocol which defines
   the workable subset of transfer modes.  For example, the file
   transfer protocol will not work just with the indefinite bit stream
   modes.  At least, for control information one of the other two modes
   is required.  Again, the use of information separator and abort
   functions provided in DTP (see SPECIFICATIONS) is defined by the
   applications protocol.  For example, in a remote job entry protocol,
   aborts may be used to stop the execution of a job while they may not



Bhushan, et al.                                                 [Page 2]

RFC 171                THE DATA TRANSFER PROTOCOL              June 1971


   cause any action in another applications protocol.

   It should also be noted that DTP does not define a data transfer
   service.  There is no standard server socket, or initial connection
   protocol defined for DTP.  What DTP defines is a mechanism for data
   transfer which can be used to provide services for block data
   transfers, file transfers, remote job entry, network mail and
   numerous other applications.

   There are to be no restrictions on the manner in which DTP is
   implemented at various sites.  For example, DTP may be imbedded in an
   applications program such as for file transfer, or it may be a
   separate service program or subroutine used by several applications
   programs.  Another implementation may employ macros or UUO's (user
   unimplemented operations on PDP-10's), to achieve the functions
   specified in DTP.  It is also possible that in implementation, the
   separation between the DTP and applications protocols be only at a
   conceptual level.

III. SPECIFICATIONS

   1.  Byte Size for Network Connection

       The standard byte size for network connections using DTP is 8-
       bit.  However, other byte sizes specified by higher-level
       applications protocols or applications programs are also allowed
       by DTP.  For the purpose of this document bytes are assumed to be
       8-bits, unless otherwise stated.

2.  Transactions

       At DTP level, all information transmitted over connection is a
       sequence of transactions.  DTP defines the rules for delimiting
       transactions. [3]

2A. Types

       The first byte of each transaction shall define a transaction
       type, as shown below.  (Note that code assignments do not
       conflict with assignments in TELNET protocol.)  The transaction
       types may be referred by the hexadecimal code assigned to them.
       The transactions types are discussed in more detail in section
       2B.








Bhushan, et al.                                                 [Page 3]

RFC 171                THE DATA TRANSFER PROTOCOL              June 1971


           Code                 Transaction Type
      Hex       Octal

      B0         260        Indefinite bit stream -- data.
      B1         261        Transparent (DLE) block--data.
      B2         262        Descriptor and counts--data.
      B3         263        Modes available (handshake).
      B4         264        Information separators (endcode).
      B5         265        Error codes.
      B6         266        Abort.
      B7         267        No operation (NoOp).
      B8         270        Indefinite bit stream--control.
      B9         271        Transparent (DLE) block--control.
      BA         272        Descriptor and counts--control.
      BB         273        (unassigned but reserved for data transfer)
      BC         274                  "         "         "
      BD         275                  "         "         "
      BE         276                  "         "         "
      BF         277                  "         "         "

   2B.  Syntax and Semantics

   2B.1  Type B0 and B8 (indefinite bitstream modes) transactions
         terminate only when the NCP connection is "closed".  There is
         no other escape convention defined in DTP at this level.  It
         should be noted, that closing connection in bitstream mode
         represents an implicit file separator (see section 2B.5).

   2B.2  Type B1 and B0 (transparent block modes) transactions terminate
         when the byte sequence DLE ETX is encountered.  The sender
         shall replace any occurrence of DLE in data stream by the
         sequence DLE DLE.  The receiver shall strip the extra DLE.  The
         transaction is assumed to by byte-oriented.  The code for DLE
         is Hex '90' or Octal '220' (this is different from the ASCII
         DLE which is Hex '10' or Octal '020).  ETX is Hex '03' or Octal
         '03' (the same as ASCII ETX) [4].

   2B.3  Type B2 and BA (descriptor and counts modes) transactions have
         three fields, a 9-byte (72-bits) descriptor field [5] and
         variable length (including zero) info and filler fields, as
         shown below.  The total length of a transaction is
         (72+info+filler) bits.









Bhushan, et al.                                                 [Page 4]

RFC 171                THE DATA TRANSFER PROTOCOL              June 1971


|<B2 or BA><Info count><NUL><Seq #><NUL><filler count>|<info><filler> |

|  3-bits    24-bits 8-bits 16-bits 8-bits  8-bits    |Variable length|

|<----- 72-bit descriptor field --------------------->|info and filler|

         Info count is a binary count of number of bits in info field,
         not including descriptor or filler bits.  Number of info bits
         is limited to (2**24 - 1), as there are 24 bits in info count
         field.

         Sequence # is a sequential count in round-robin manner of B2
         and BA type transaction.  The inclusion of sequence numbers
         would help in debugging and error control, as sequence numbers
         may be used to check for missing transactions, and aid in
         locating errors.  Hosts not wishing to implement this mechanism
         should have all 1's in the field.  The count shall start from
         zero and continue sequentially to all 1's, after which it is
         reset to all zeros.  The permitted sequence numbers are one
         greater than the previous, and all 1's.

         Filler count is a binary count of bits used as fillers (i.e.,
         not information) after the end of meaningful data.  Number of
         filler bits is limited to 255, as there are 8 bits in filler