RFC 916 (rfc916) - Page 3 of 54

Reliable Asynchronous Transfer Protocol (RATP)

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