rfc916.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                            G. Finn
Request for Comments: 916                                            ISI
                                                            October 1984

             RELIABLE ASYNCHRONOUS TRANSFER PROTOCOL (RATP)


Status of This Memo

   This RFC suggests a proposed protocol for the ARPA-Internet
   community, and requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited.

   This paper proposes and specifies a protocol which allows two
   programs to reliably communicate over a communication link.  It
   ensures that the data entering one end of the link if received
   arrives at the other end intact and unaltered.  The protocol, named
   RATP, is designed to operate over a full duplex point-to-point
   connection.  It contains some features which tailor it to the RS-232
   links now in common use.

Introduction

   We are witnessing today an explosive growth in the small or personal
   computer market.  Such inexpensive computers are not normally
   connected to a computer network.  They are most likely stand-alone
   devices.  But virtually all of them have an RS-232 interface.  They
   also usually have a modem.  This allows them to communicate over the
   telephone with any other similarly equipped computer.

   The telephone system is a pervasive network, but one of the
   characteristics of the telephone system is the unpredictable quality
   of the circuit.  The standard telephone circuit is designed for voice
   communication and not data communication.  Voice communication
   tolerates a much higher degree of 'noise' than does a data circuit,
   so a voice circuit is tolerant of a much higher level of noise than
   is a data circuit.  Thus it is not uncommon for a byte of data
   transferred over a telephone circuit to have noise inserted.  For the
   same reason it is also not uncommon to have spurious data bytes added
   to the data stream.

   The need for a method of reliably transferring data over an RS-232
   point-to-point link has become severe.  As the number of powerful
   personal computers grows, the need for them to communicate with one
   another grows as well.  The new markets and new services that these
   computers will eventually allow their users to access will rely
   heavily upon the telephone system.  Services like electronic mail,
   electronic banking, ordering merchandise from home with a personal
   computer, etc.  As the information revolution proceeds data itself
   will become a commodity.  All require accuracy of the data sent or
   received.


Finn                                                            [Page 1]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


1. Philosopy of Design

   Many tradeoffs were made in designing this protocol.  Decisions were
   made by above all ensuring reliability and then by favoring
   simplicity of implementation.  It is hoped that this protocol is
   simple enough to be implemented not only by small computers but also
   by stand alone devices incorporating microcomputers which accept
   commands over RS-232 lines.  Sophisticated but unnecessary features
   such as dynamic window management [TCP 81] were left out for
   simplicity's sake.  Having several packets outstanding at a time was
   eliminated for the same reason, and data queued to send when a
   connection is closed remotely is discarded.  This eliminates two
   states from the protocol implementation.

   The reader may ask why define this protocol at all, there are after
   all already RS-232 transport protocols in use.  This is true but some
   lack one or more features vitally important or are too complex.  See
   Appendix II for a brief survey.

      - A protocol which can only transfer data in one direction is
        unable to use a single RS-232 link for a full-duplex connection.
        As such it cannot act as a bridge between most computer
        networks.  Also it is not capable of supporting any applications
        requiring the two-way exchange of data.  In particular it is not
        a platform suitable for the creation of most higher level
        applications.  Unidirectional flow of data is sufficient for a
        weak implementation of file transfer but insufficient for remote
        terminal service, transaction oriented processing, etc.

      - Some of the existing RS-232 transport protocols allow the use of
        only fixed size packets or do not allow the receiver to place a
        limit on the sender's packets.  Where that block size is too
        large for the receiving end concentrator, that concentrator is
        likely to immediately invoke flow control.  This results in many
        dropped and damaged packets.  The receiver must be able to
        inform the sender at connection initiation what is the maximum
        packet size it is prepared to receive.

      - Some protocols have a number of features which may or may not be
        implemented at each site.  Examples are, several checksumming
        algorithms, differing data transmission restrictions, sometimes
        8-bit data, sometimes restricted ASCII subsets, etc.  The
        resulting requirement that all sites implement all the various
        features is rarely met.

   Finally, the size of this document may be imposing.  The document
   attempts to fully specify the behavior of the protocol.  A careful


Finn                                                            [Page 2]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


   exposition of the protocol's behavior under all circumstances is
   necessary to answer any questions an implementor might have, to make
   it possible to verify the protocol, etc.  This size of this
   specification should not be taken as an indication of the difficulty
   of implementing it.

   1.1. The Host Environment

      This protocol is designed to operate on any point-to-point
      communication link capable of transmitting and receiving data.  It
      is not necessary that the link be asynchronous.  Because neither
      end of a connection has control over when the other decides to
      transmit, the link should be full duplex.  It is expected that in
      the vast majority of circumstances an asynchronous full-duplex
      RS-232 link will be used.

      In practice this protocol could reside anywhere from the RS-232
      driver software on a microcomputer in a concentrator all the way
      to the user software level.  Ideally it properly resides inside
      the host operating system or concentrator.  It should be an option
      associated with communication link which is selectable by the user
      program.  If reliable data transmission were of great importance
      then the software would choose the option.  Once the option were
      chosen the initial connection handshaking would begin.

      There are many cases where this protocol will not reside in a host
      operating system (initially this will always be so).  In addition
      there are many pieces of stand-alone equipment which accept
      commands over an RS-232 link.  A plotter is such an example.  To
      have a several hour plot ruined by noise on an unreliable data
      line is an all too often occurrence.  The sending and receiving
      sides of the protocol should be as simple as possible allowing
      applications software and stand alone devices to utilize the
      protocol with little penalty of time or space.

   1.2. Relation to Other Protocols

      The "layering" concept has become the accepted way of designing
      communications protocols.  Because this protocol will operate in a
      point-to-point environment it comprises both the datagram and
      reliable connection layers.  No multi-network capability is
      implied.  Where a link using this protocol bridges differing
      networks it is expected that other protocols like TCP will have
      their packets fragmented and encapsulated inside the packets of
      this protocol.




Finn                                                            [Page 3]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


2. Packet Specification

   RATP transmits data over a full-duplex communication link.  Data may
   be transmitted in both directions over the link.  A stream of data is
   communicated by being broken up into 8-bit pieces called octets.
   These octets are serially accumulated to form a packet.  The packet
   is the unit of data communicated over the link.  The protocol
   virtually guarantees that the data transmitted at one end, if
   received, arrives unaltered and intact at the other end.

   Within an octet all eight bits contain data.  All eight bits must be
   preserved by the link interface and associated device driver.  In
   many operating systems this is ensured by placing the connection into
   RAW or BINARY data mode.  During normal operation packets are
   transmitted and acknowledged one at a time over the link in each
   direction.  Each packet is composed of a HEADER followed by a DATA
   portion.  The DATA portion may be empty.

      NOTE: There are some older operating systems and devices which do
      not permit 8-bit communication over an RS-232 link.  Most of these
      allow restricted 7-bit communication.  RATP can automatically
      detect this situation during connection initiation and utilizes a
      special packing strategy when full 8-bit communication is not
      possible.  This is entirely transparent to any client software.
      See Appendix I for a discussion of this case.
























Finn                                                            [Page 4]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


   2.1. Header Format

      Byte No.

             +-------------------------------+
             |                               |
         1   |          Synch Leader         | Hex 01
             |                               |
             +-------------------------------+
             | S | A | F | R | S | A | E | S |
         2   | Y | C | I | S | N | N | O | O | Control
             | N | K | N | T |   |   | R |   |
             +-------------------------------+
             |                               |
         3   |      Data length (0-255)      |
             |                               |
             +-------------------------------+
             |                               |
         4   |        Header Checksum        |
             |                               |
             +-------------------------------+

                       Header Portion of a Packet

      2.1.1. Synch Leader

         RS-232 provides a self-clocking communications medium.  The
         wires over which data flows are often placed in 'noisy'
         environments where the noise can appear as added unwanted data.
         For this reason the beginning of a packet is denoted by a one
         octet SYNCH pattern.  This allows the receiver to discard noise
         which appears on the connection prior to the reception of a
         packet.  The SYNCH pattern is defined to be the one octet hex
         01, the ASCII Start Of Header character <SOH>.

         The SYNCH pattern should ideally be unlikely to occur as the
         result of noise.  Differing modems, etc. have differing
         responses to noise so this is hard to achieve.  The pattern
         chosen is thought to be a good compromise since many modems
         manifest noise by setting the high order bits.  Situations will
         occur in which receiver is scanning for the beginning of a
         packet and a spurious SYNCH pattern is seen.  To detect
         situations of this type a header checksum is provided (see
         below).





Finn                                                            [Page 5]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


      2.1.2. Control Bits

         The first octet following the SYNCH pattern contains a 5-bit
         field of control flags and two 1-bit sequence number fields.
         The last bit is reserved and must be zero.

         2.1.2.1. SYN - Synchronize Flag

            Synchronize the connection.  No data may be sent in a packet
            which has the SYN flag set.

         2.1.2.2. ACK - Acknowledge Flag

            Acknowledge number is significant.  Data may accompany a
            packet which has this flag set as long as neither of SYN,
            RST, nor FIN are also set.  Once a connection has been
            established this is always set.

         2.1.2.3. RST - Reset Flag

            Reset the connection.  This is a method by which one end of
            a connection can reset the other when an anomalous condition
            is detected.  No data may be sent in a packet which has the
            RST flag set.

         2.1.2.4. FIN - Finishing Flag

            This indicates that no more data will be sent to the other
            end of the connection.  It also indicates that no more data
            will be accepted.  No data may be sent in a packet which has
            the FIN flag set.

         2.1.2.5. SN - Sequence Number

            The Sequence Number associated with this packet.

         2.1.2.6. AN - Acknowledge Number

            If the ACK control flag is set this is the next Sequence
            Number the sender of the packet is expecting to receive.

         2.1.2.7. EOR - End of Record

            This bit is provided as an aid for higher level protocols
            which may need to fragment their packets.  The Internet
            protocol for example often uses packets as large as 576
            octets.  A packet of such size would require fragmentation


Finn                                                            [Page 6]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


            when transported using this protocol. The EOR bit if set
            provides information to the higher level that a record is
            terminated in this packet.  It is for information only and
            is the responsibility of the higher level to set/clear it
            when building packets to send.  The interface to the
            protocol must provide a method of reading/setting/clearing
            this bit.

         2.1.2.8. SO - Single Octet

            One application thought to be of special importance is
            single character transmission --- a user communicates from
            the keyboard of a personal computer to another computer over
            an unreliable link.  Since rapid interactive response is
            desirable it is expected that many of the characters typed
            will be transmitted individually.  To minimize the overhead
            of this special case the SO control flag is provided.

            The SO flag has no meaning if either the SYN, RST, or FIN
            flags are set.  Assume none of those flags are set, then if
            the SO flag is set it indicates that a single octet of data
            is contained in this packet. Since the amount of data is