doc: Add RFC documents

1 files changed, 3078 insertions, 0 deletions

diff --git a/doc/rfc/rfc916.txt b/doc/rfc/rfc916.txt
new file mode 100644
index 0000000..a13497f
--- /dev/null
+++ b/doc/rfc/rfc916.txt
@@ -0,0 +1,3078 @@
+
+
+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
+            known to be one octet the LENGTH field is superfluous and
+            itself contains the data octet.  The data portion of the
+            packet is not transmitted.
+
+            The SO flag removes the need to transmit the data portion of
+            the packet in this special case.  Without the SO flag seven
+            octets would be required of the packet, with it only four
+            are needed and so transmission efficiency is improved by 40
+            percent.  The header checksum protects the single octet of
+            data.
+
+      2.1.3. Length
+
+         The second octet following the SYNCH pattern holds length
+         information.  If the SYN bit is present this contains the
+         maximum number of data octets the receiver is allowed to
+         transmit in any single packet to the sender.  This quantity is
+         called the MDL.  A sender may indicate his unwillingness to
+         accept any data octets by specifying an MDL of zero.  In this
+         case presumably all the data would be moving from the sender to
+         the receiver.  Obviously if data is to be transmitted both
+         sides of a connection cannot have an MDL of zero.
+
+         If neither the SYN, RST, nor FIN flags are set this is an 8-bit
+         field called LENGTH.  In this case if the SO flag bit is set
+
+
+Finn                                                            [Page 7]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+         then LENGTH contains a single octet of data.  Otherwise it
+         contains the count of data octets in this packet.  From zero
+         (0) to MDL octets of data may appear in a single packet.  MDL
+         is limited to a maximum of 255.
+
+      2.1.4. Header Checksum
+
+         The header checksum algorithm is the 8-bit equivalent of the
+         16-bit data checksum detailed below.  It is built and processed
+         in an similar manner but is eight bits wide instead of sixteen.
+         When sending the header checksum octet is initially cleared.
+         An 8-bit sum of the control, length, and header checksum octets
+         is formed employing end-around carry.  That sum is then
+         complemented and stored in the header checksum octet.  Upon
+         receipt the 8-bit end-around carry sum is formed of the same
+         three octets.  If the sum is octal 377 the header is presumed
+         to be valid.  In all other cases the header is assumed to be
+         invalid.
+
+         The reasons for providing this separate protection to the
+         header are discussed in the chapter dealing with error
+         handling.  The header checksum covers the control and data
+         length octets.  It does not include the SYNCH pattern.
+
+   2.2. Data Format
+
+      The data portion of a packet immediately follows the header if the
+      SO flag is not set and LENGTH > 0.  It consists of LENGTH data
+      octets  immediately followed by two data checksum octets.  If
+      present the data portion contains LENGTH+2 octets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finn                                                            [Page 8]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+      Data Byte No.
+
+                  +-------------------------------+
+         1        |                               | High order \
+                  +--                           --+             > Word
+         2        |                               | Low order  /
+                  +--                           --+
+         .        |            Data               | High order \
+                  +--                           --+             > Word
+         .        |                               | Low order  /
+                  +--                           --+
+         LENGTH   |                               | High order \
+                  +-------------------------------+             > Word
+                  |   Imaginary padding octet 0   | Low order  /
+                  +-------------------------------+
+         LENGTH+1 |                               | High order \
+                  +--       Data Checksum       --+             > Word
+         LENGTH+2 |                               | Low order  /
+                  +-------------------------------+
+
+                        Data Portion of a Packet
+
+      2.2.1. Data Checksum
+
+         The last two octets of the data portion of a packet are a data
+         checksum.  A 16-bit checksum is used by this protocol to detect
+         incorrectly transmitted data.  This has shown itself to be a
+         reliable method for detecting most categories of bit drop out
+         and bit insertion.  While it does not guarantee the detection
+         of all such errors the probability of such an error going
+         undetected is on the order of 2**(-16).
+
+         The checksum octets follow the data to enable the sender of a
+         packet to compute the checksum while transmitting a packet and
+         the receiver to compute the checksum while receiving the
+         packet.  Thus neither must store the packet and then process
+         the data for checksumming in a separate pass.
+
+         Order of Transmission
+
+            The order in which the 8-bit octets are assembled into
+            16-bit words, which is the low order octet and which is the
+            high, must be rigidly specified for the purpose of computing
+            16-bit checksums.  We specify the big endian ordering in the
+            diagram above [Cohen 81].
+
+
+
+
+Finn                                                            [Page 9]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+         Checksum Algorithm
+
+            The checksum algorithm chosen is similar to that used by
+            IP/TCP protocols [IP 81] [TCP 81].  This algorithm has shown
+            itself to be both reliable and relatively easy to compute.
+            The interested reader may refer to [TCP Checksum 78] for a
+            more thorough discussion of its properties.
+
+         The checksum algorithm is:
+
+            SENDER
+
+               The unsigned sum of the 16-bit words of the data portion
+               of the packet is formed.  Any overflow is added into the
+               lowest order bit.  This sum does not include the header
+               portion of the packet.  For the purpose of building a
+               packet for transmission the two octet checksum field is
+               zero.  The sum formed is then bit complemented and
+               inserted into the checksum field before transmission.
+
+               If the total number of data octets is odd then the last
+               octet is padded to the right (low order) with zeros to
+               form a 16-bit word for checksum purposes.  This pad octet
+               is not transmitted as part of the packet.
+
+            RECEIVER
+
+               The sum is computed as above but including the values
+               received in the checksum field.  If the 16-bit sum is
+               octal 177777 then the data is presumed to be valid.  In
+               all other cases the data is presumed to be invalid.
+
+         This unsigned 16-bit sum adds 16-bit quantities with any
+         overflow bit added into the lowest order bit of the sum.  This
+         is called 'end around carry'.  End around carry addition
+         provides several properties: 1) It provides full commutivity of
+         addition (summing in any order is equivalent), and 2) If you
+         apply a given rotation to each quantity before addition and
+         when the final total is formed apply the inverse rotation, then
+         the result will be equivalent to any other rotation chosen.
+         The latter property gives little endian machines like a PDP-11
+         the go ahead to pick up 16-bit quantities and add them in byte
+         swapped order.
+
+
+
+
+
+
+Finn                                                           [Page 10]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+            The PDP-11 code to calculate the checksum is:
+
+                     CLR R0         ; R0 will get the checksum
+                                    ; R2 contains LENGTH count
+               LOOP: ADD (R1)+,R0   ; Add the next 16-bit byte
+                     ADC R0         ; Make any carry be end around
+                     SOB R2,LOOP    ; Loop over entire packet
+                     COM R0         ; Bit complement result
+
+   2.3. Sequence Numbers
+
+      Sequence numbers work with acknowledge numbers to inform the
+      sender that his last data packet was received, and to inform the
+      receiver of the sequence number of the next data packet it expects
+      to see.  When the ACK flag is set in a packet the AN field
+      contains the sequence number of the next data packet it expects
+      from the sender.  The sender looks at the AN field and by
+      implication knows that the packet he just sent should have had a
+      sequence number of:
+
+         <AN received-1 modulo 2>
+
+      If it did have that number that packet is considered to have been
+      acknowledged.
+
+      Similarly, the receiver expects the next data packet it sees to
+      have an SN field value equal to the AN field of the last
+      acknowledge message it sent.  If this is not the case then the
+      receiver assumes that it is receiving a duplicate of a data packet
+      it earlier acknowledged.  This implies that the packet containing
+      the acknowledgment did not arrive and therefor the packet that
+      contained the acknowledgment should be retransmitted.  The
+      duplicate data packet is discarded.
+
+      The only packets which require acknowledgment are packets
+      containing status flags (SYN, RST, FIN, or SO) or data.  A packet
+      which contains only an acknowledgment, i.e. <AN=n><CTL=ACK>, does
+      not require a response (it contains no status flags or data).
+
+      Both the AN and SN fields are a single bit wide.  Since at most
+      one packet is in the process of being sent/acknowledged in a
+      particular direction at any one time a single bit is sufficient to
+      provide a method of duplicate packet detection and removal of a
+      packet from the retransmission queue.  The arithmetic to advance
+      these numbers is modulo 2.  Thus when a data packet has been
+      acknowledged the sender's next sequence number will be the current
+      one, plus one modulo 2:
+
+
+Finn                                                           [Page 11]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+         <SN = SN + 1 modulo 2>
+
+      The individual acknowledgment of each packet containing data can
+      mislead one into thinking that side A of a connection cannot send
+      data to side B until it receives a packet from B. That only then
+      can it acknowledge B's packet and place in the acknowledging
+      packet some data of its own.  This is not the case.
+
+      As long as its last packet sent requiring a response has been
+      acknowledged each side of a connection is free to send a data
+      packet whenever it wishes.  Naturally, if one side is sending a
+      data packet and it also must acknowledge receipt of a data packet
+      from the other side, it is most efficient to combine both
+      functions in a single packet.
+
+   2.4. Maximum Packet Size
+
+      The maximum packet size is:
+
+         SYNCH + HEADER + Data Checksum + 255 = 261 octets
+
+      There is therefor no need to allocate more than that amount of
+      storage for any received packets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finn                                                           [Page 12]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+3. The Opening and Closing of a Connection
+
+   3.1. Opening a Connection
+
+      A "three-way handshake" is the procedure used to establish a
+      connection.  It is normally initiated by one end of the connection
+      and responded to by the other.  It will still work if both sides
+      simultaneously initiate the procedure.  Experience has shown that
+      this strategy of opening a connection reduces the probability of
+      false connections to an acceptably low level.
+
+      The simplest form of the three-way handshake is illustrated in the
+      diagram below.  The time order is line by line from top to bottom
+      with certain lines numbered for reference.  User events are placed
+      in brackets as in [OPEN].  An arrow (-->) represents the direction
+      of flow of a packet and an ellipsis (...) indicates a packet in
+      transit.  Side A and side B are the two ends of the connection.
+      An "XXX" indicates a packet which is lost or rejected.  The
+      contents of the packet are shown on the center of each line.  The
+      state of both connections is that caused by the departure or
+      arrival of the packet represented on the line.  The contents of
+      the data portion of a packet are left out for clarity.
+
+      Side A                                             Side B
+
+      1. CLOSED                                          LISTEN
+
+      2. [OPEN request]
+          SYN-SENT ->   <SN=0><CTL=SYN><MDL=n>     ...
+
+      3.                                           -->   SYN-RECEIVED
+              ... <SN=0><AN=1><CTL=SYN,ACK><MDL=m> <--
+
+      4. ESTABLISHED <--
+              -->    <SN=1><AN=1><CTL=ACK><DATA>   ...
+
+      5.                                           -->   ESTABLISHED
+
+      In line 2 above the user at side A has requested that a connection
+      be opened.  Side A then attempts to open a connection by sending a
+      SYN packet to side B which is in the LISTEN state.  It specifies
+      its initial sequence number, here zero.  It places in the LENGTH
+      field of the header the largest number of data octets it can
+      consume in any one packet (MDL).  The MDL is normally positive.
+      The action of sending this packet places A in the SYN-SENT state.
+
+      In line 3 side B has just received the SYN packet from A. This
+
+
+Finn                                                           [Page 13]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+      places B in the SYN-RECEIVED state.  B now sends a SYN packet to A
+      which acknowledges the SYN it just received from A. Note that the
+      AN field indicates B is now expecting to hear SN=1, thus
+      acknowledging the SYN packet from A which used SN=0.  B also
+      specifies in the LENGTH field the largest number of data octets it
+      is prepared to consume.
+
+      Side A receives the SYN packet from B which acknowledges A's
+      original SYN packet in line 4.  This places A in the ESTABLISHED
+      state.  Side A can now be confident that B expects to receive more
+      packets from A.
+
+      A is now free to send B the first DATA packet.  In line 5 upon
+      receipt of this packet side B is placed into the ESTABLISHED
+      state.  DATA cannot be sent until the sender is in the ESTABLISHED
+      state.  This is because the LENGTH field is used to specify the
+      MDL when opening the connection.
+
+   3.2. Recovering from a Simultaneous Active OPEN
+
+      It is of course possible that both ends of a connection may choose
+      to  perform an active OPEN simultaneously.  In this case neither
+      end of the connection is in the LISTEN state, both send SYN
+      packets.  A reliable bidirectional protocol must recover from this
+      situation.  It should recover in such a manner that the connection
+      is successfully initiated.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finn                                                           [Page 14]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+      Side A                                             Side B
+
+      1. CLOSED                                          CLOSED
+
+      2. [OPEN request]
+         SYN-SENT -->  <SN=0><CTL=SYN><MDL=n>       ...
+
+      3.     ...                                         [OPEN request]
+                       <SN=0><CTL=SYN><MDL=m>       <--  SYN-SENT
+
+      4.                                            -->  SYN-RECEIVED
+             ...  <SN=0><AN=1><CTL=SYN,ACK><MDL=m>  <--
+
+      5. (packet finally arrives)
+         SYN-RECEIVED  <--  <SN=0><CTL=SYN><MDL=m>
+
+             -->  <SN=0><AN=1><CTL=SYN,ACK><MDL=n>  -->  ESTABLISHED
+              ...       <SN=1><AN=1><CTL=ACK>       <--
+
+      6. (packet finally arrives)
+         ESTABLISHED <-- <SN=0><AN=1><CTL=SYN,ACK><MDL=m>
+                     -->   <SN=1><AN=1><CTL=ACK>    ...
+
+      During simultaneous connection both  sides  of  the  connection
+      cycle  from  the CLOSED state through SYN-SENT to SYN-RECEIVED,
+      and finally to ESTABLISHED.
+
+   3.3. Detecting a Half-Open Connection
+
+      Any computer may crash after a connection has been established.
+      After recovering from the crash it may attempt to open a new
+      connection.  The other end must be able to detect this condition
+      and treat it as an error.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finn                                                           [Page 15]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+      Side A                                             Side
+
+      1. ESTABLISHED                                     ESTABLISHED
+
+                -->   <SN=0><AN=1><CTL=ACK><DATA>  ...
+                                                   -->
+      (crashes)
+
+      2.        XXX   <SN=1><AN=1><CTL=ACK><DATA>  <--
+
+      3. (attempts to open new connection )
+                -->    <SN=0><CTL=SYN><MDL=m>      -->
+                ...  <SN=0><AN=1><CTL=RST,ACK>     <--   (abort)
+                                                         CLOSED
+
+      4.        <--
+      (connection refused)
+         CLOSED
+
+   3.4. Closing a Connection
+
+      Either side may choose to close an established connection.  This
+      is accomplished by sending a packet with the FIN  control bit set.
+      No  data may appear in a FIN packet.  The other end of the
+      connection responds by shutting down its end of the connection and
+      sending a FIN, ACK in response.
+
+      Side A                                             Side B
+
+      1. ESTABLISHED                                     ESTABLISHED
+
+      2. [CLOSE request from user]
+         FIN-WAIT  -->     <SN=0><AN=1><CTL=FIN>    ...
+
+      3.                                            -->  LAST-ACK
+                   ...   <SN=1><AN=1><CTL=FIN,ACK>  <--
+
+      4. TIME-WAIT <--
+                   -->     <SN=1><AN=0><CTL=ACK>    ...
+
+      5.                                            -->  CLOSED
+
+      6. (after 2*SRTT time passes)
+         CLOSED
+
+      In line 2 the user on side A of the fully opened connection has
+      decided to close it down by issuing a CLOSE call.  No more data
+
+
+Finn                                                           [Page 16]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+      will be accepted for sending.  If data remains unsent a message
+      "Warning: Unsent data remains." is communicated to the user.  No
+      more data will be received.  A packet containing a FIN but no data
+      is constructed and sent.  Side A goes into the FIN-WAIT state.
+
+      Side B sees the FIN sent and immediately builds a FIN, ACK packet
+      in response.  It then goes into the LAST-ACK state.  The FIN, ACK
+      packet is received by side A and an answering ACK is immediately
+      sent.  Side A then goes to the TIME-WAIT state.  In line 5 side B
+      receives the final acknowledgment of its FIN, ACK packet and goes
+      to the CLOSED state.  In line 6 after waiting to be sure its last
+      acknowledgment was received side A goes to the CLOSED state (SRTT
+      is the Smoothed Round Trip Time and is defined in section 6.3.1).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finn                                                           [Page 17]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+4. Packet Reception
+
+   The act of receiving a packet is relatively straightforward.  There
+   are a few points which deserve some discussion.  This chapter will
+   discuss packet reception stage by stage in time order.
+
+   Synch Detection
+
+      The first stage in the reception of a packet is the discovery of a
+      SYNCH pattern.  Octets are read continuously and discarded until
+      the SYNCH pattern is seen.  Once SYNCH has been observed proceed
+      to the Header Reception stage.
+
+   Header Reception
+
+      The remainder of the header is three octets in length.  No further
+      processing can continue until the complete header has been read.
+      Once read the header checksum test is performed.  If this test
+      fails it is assumed that the current SYNCH pattern was the result
+      of a data error.  Since the correct SYNCH may appear immediately
+      after the current one, go back to the Synch Detection stage but
+      treat the three octets of the header following the bad SYNCH as
+      new input.
+
+      If the header checksum test succeeds then proceed to the Data
+      Reception stage.
+
+   Data Reception
+
+      A determination of the remaining length of the packet is made.  If
+      either of the SYN, RST, SO, or FIN flags are set then legally the
+      entire packet has already been read and it is considered to have
+      'arrived'.  No data portion of a packet is present when one of
+      those flags is set.  Otherwise the LENGTH field specifies the
+      remaining amount of data to read.  In this case if the LENGTH
+      field is zero then the packet contains no data portion and it is
+      considered to have arrived.
+
+      We now assume that a data portion is present and LENGTH was
+      non-zero.  Counting the data checksum LENGTH+2 octets must now be
+      read.  Once read the data checksum test is performed.  If this
+      test fails the entire packet is discarded, return to the Synch
+      Detection stage.  If the test succeeds then the packet is
+      considered to have arrived.
+
+
+
+
+
+Finn                                                           [Page 18]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+   Once arrived the packet is released to the upper level protocol
+   software.  In a multiprocess implementation packet reception would
+   now begin again at the Synch Detection stage.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finn                                                           [Page 19]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+5. Functional Specification
+
+   A convenient model for the discussion and implementation of protocols
+   is that of a state machine.  A connection can be thought of as
+   passing through a variety of states, with possible error conditions,
+   from its inception until it is closed.  In such a model each state
+   represents a known point in the history of a connection.  The
+   connection passes from state to state in response to events.  These
+   events are caused by user calls to the protocol interface (a request
+   to open or close a connection, data to send, etc.), incoming packets,
+   and timeouts.
+
+   Information about a connection must be maintained at both ends of
+   that connection.  Following the terminology of [TCP 81] the
+   information necessary to the successful operation of a connection is
+   called the Transmission Control Block or TCB.  The user requests to
+   the protocol interface are OPEN, SEND, RECEIVE, ABORT, STATUS, and
+   CLOSE.
+
+   This chapter is broken up into three parts.  First a brief
+   description of each protocol state will be presented.  Following this
+   is a slightly more detailed look at the allowed transitions which
+   occur between states.  Finally a detailed discussion of the behavior
+   of each state is given.
+
+   5.1. Protocol States
+
+      The states used to describe this protocol are:
+
+         LISTEN
+
+            This state represents waiting for a connection from the
+            other end of the link.
+
+         SYN-SENT
+
+            This represents waiting for a matching connection request
+            after having sent a connection request.
+
+         SYN-RECEIVED
+
+            This represents waiting for a confirming connection request
+            acknowledgment after having both received and sent a
+            connection request.
+
+
+
+
+
+Finn                                                           [Page 20]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+         ESTABLISHED
+
+            This state represents a connection fully opened at both
+            ends.  This is the normal state for data transfer.
+
+         FIN-WAIT
+
+            In this state one is waiting for a connection termination
+            request from the other end of the connection and an
+            acknowledgment of a termination request previously sent.
+
+         LAST-ACK
+
+            This end of the connection has seen and acknowledged a
+            termination request from the other end.  This end has
+            responded with a termination request of its own and is now
+            expecting an acknowledgment of that request.
+
+         CLOSING
+
+            This represents waiting for an acknowledgment of a
+            connection termination request.
+
+         TIME-WAIT
+
+            This represents waiting for enough time to pass to be sure
+            that the other end of the connection received the
+            acknowledgment of its termination request.
+
+         CLOSED
+
+            A fictional state which represents a completely terminated
+            connection.  If either end of a connection is in this state
+            it will neither send nor receive data or control packets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finn                                                           [Page 21]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+   5.2. State Transitions
+
+      This section describes events which cause the protocol to depart
+      from its current state.  A brief mention of each state is
+      accompanied by a list of departure events and to which state the
+      protocol goes as a result of those events.  Departures due to the
+      presence of a RST flag are not shown.
+
+      5.2.1. LISTEN
+
+         This is a request to listen for any connection from the other
+         end of the link.  In this state, no packets are sent.  The
+         connection may be thought of as half-open.  A STATUS request
+         will return to the caller this information.
+
+         Arrived at from the CLOSED state in response to a passive OPEN.
+         In a passive OPEN no packets are sent, the interface is waiting
+         for the initiation of a connection from the other end of the
+         link.  Also this state can be reached in certain cases in
+         response to an RST connection reset request.
+
+         Departures
+
+            - A CLOSE request is made by the user.  Delete the half-open
+              TCB and go to the CLOSED state.
+
+            - A packet arrives with the SYN flag set.  Retrieve the
+              sender's MDL he placed into the LENGTH field.  Set AN to
+              be received SN+1 modulo 2.  Build a response packet with
+              SYN, ACK set.  Choose your MDL and place it into the
+              LENGTH octet.  Choose your initial SN, place in AN.  Send
+              this packet and go to the SYN-RECEIVED state.
+
+      5.2.2. SYN-SENT
+
+         Arrived at from the CLOSED state in response to a user's active
+         OPEN request.
+
+         Departures
+
+            - A CLOSE request is made by the user.  Delete the TCB and
+              go to the CLOSED state.
+
+            - A packet arrives with the SYN flag set.  Retrieve the
+              sender's MDL he placed into the LENGTH field.  Set AN to
+
+
+
+
+Finn                                                           [Page 22]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+              be received SN+1 modulo 2.  Build a response packet with
+              ACK set, place in AN.  Send this packet and go to the
+              SYN-RECEIVED state.
+
+            - A packet arrives with the SYN, ACK flags set.  Retrieve
+              the sender's MDL he placed into the LENGTH field.  Set AN
+              to be received SN+1 modulo 2.  Build a response packet
+              with ACK set.  Set SN to be SN+1 modulo 2, place SN and AN
+              into the header.  Remembering the other end's MDL, build
+              data portion of packet.  Send this packet and go to the
+              ESTABLISHED state.
+
+      5.2.3. SYN-RECEIVED
+
+         Arrived at from the LISTEN and SYN-SENT states in response to
+         an arriving SYN packet.
+
+         Departures
+
+            - A CLOSE request is made by the user.  Create a packet with
+              FIN set.  Send it and go to the FIN-WAIT state.
+
+            - A packet arrives with the ACK flag set.  This packet
+              acknowledges a previous SYN packet.  Go to the ESTABLISHED
+              state.  The TCB should now note the connection is fully
+              opened.
+
+            - A packet arrives with the FIN flag set.  The other end has
+              decided to close the connection.  Create a packet with
+              FIN, ACK set.  Send it and go to the LAST-ACK state.
+
+      5.2.4. ESTABLISHED
+
+         This state is the normal state for a connection.  Data packets
+         may be exchanged in both directions (MDL allowing).  It is
+         arrived at from the SYN-RECEIVED and SYN-SENT states in
+         response to the completion of connection initiation.
+
+         Departures
+
+            - In response to a CLOSE request from the user.  Set AN to
+              be most recently received SN+1 modulo 2.  Build a packet
+              with FIN set.  Set SN to be SN+1 modulo 2, place SN and AN
+              into the header and send the packet.  Go to the FIN-WAIT
+              state.
+
+            - A packet containing a FIN is received.  Set AN to be
+
+
+Finn                                                           [Page 23]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+              received SN+1 modulo 2.  Build a response packet with both
+              FIN and ACK set.  Set SN to be SN+1 modulo 2, place SN and
+              AN into the header.  No data portion is built.  Send this
+              packet and go to the LAST-ACK state.
+
+      5.2.5. FIN-WAIT
+
+         Arrived at from either the SYN-RECEIVED state or from the
+         ESTABLISHED state.  In both cases the user had requested a
+         CLOSE of the connection and a packet with a FIN was sent.
+
+         Departures
+
+            - A FIN, ACK packet is received which acknowledges the FIN
+              just sent.  Go to the TIME-WAIT state.
+
+            - A FIN packet is received which indicates the other end of
+              the connection has simultaneously decided to close.  Set
+              AN=received SN+1 modulo 2, and SN=SN+1 modulo 2.  Send a
+              response packet with the ACK set.  Go to the CLOSING
+              state.
+
+      5.2.6. LAST-ACK
+
+         Arrived at from the ESTABLISHED and SYN-RECEIVED states.
+
+         Departures
+
+            - An ACK is received for the last packet sent which was a
+              FIN.  Delete the TCB and go to the CLOSED state.
+
+      5.2.7. CLOSING
+
+         Arrived at from the FIN-WAIT state.
+
+         Departures
+
+            - An ACK is received for the last packet sent which was a
+              FIN.  Go to the TIME-WAIT state.
+
+      5.2.8. TIME-WAIT
+
+         Arrived at from the FIN-WAIT and CLOSING states.
+
+
+
+
+
+
+Finn                                                           [Page 24]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+         Departures
+
+            - This states waits until 2*SRTT time has passed.  It then
+              deletes the TCB associated with the connection and goes to
+              the CLOSED state.
+
+      5.2.9. CLOSED
+
+         This state can be arrived at for a number of reasons: 1) while
+         in the LISTEN state the user requests a CLOSE, 2) while in the
+         SYN-SENT state the user requests a CLOSE, 3) while in the
+         TIME-WAIT state the 2*SRTT time period has elapsed, and 4)
+         while in the LAST-ACK state an arriving packet has an ACK of
+         the previously sent FIN packet.
+
+         In this state no data is read or sent over the link.  To leave
+         this state requires an outside request to open a new
+         connection.
+
+         Departures
+
+            - User requests an active OPEN.  Create a packet with SYN
+              set.  Choose your MDL and place it into the LENGTH octet.
+              Choose your initial SN.  AN is immaterial.  Send this
+              packet and go to the SYN-SENT state.  The TCB for this
+              connection is created.  The connection may be thought of
+              as half-open.  A STATUS request will return to the caller
+              this information.
+
+            - User requests a passive OPEN.  The TCB for this connection
+              is created.  The connection may be thought of as
+              half-open.  A STATUS request will return to the caller
+              this information.  Go to the LISTEN state.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finn                                                           [Page 25]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+   5.3. State Behavior
+
+      This section discusses in detail the behavior of each state in
+      response to the arrival of a packet.  In what follows a packet is
+      not considered to have arrived until it has passed a number of
+      tests (see the chapter entitled: Packet Reception).
+
+      The method chosen to describe state behavior is tabular.  Each
+      state is listed opposite a sequence of named procedures to execute
+      whenever a packet has arrived.
+
+      STATE                BEHAVIOR
+      =============+========================
+      LISTEN       |  A
+      -------------+------------------------
+      SYN-SENT     |  B
+      -------------+------------------------
+      SYN-RECEIVED |  C1  D1  E  F1  H1
+      -------------+------------------------
+      ESTABLISHED  |  C2  D2  E  F2  H2  I1
+      -------------+------------------------
+      FIN-WAIT     |  C2  D2  E  F3  H3
+      -------------+------------------------
+      LAST-ACK     |  C2  D3  E  F3  H4
+      -------------+------------------------
+      CLOSING      |  C2  D3  E  F3  H5
+      -------------+------------------------
+      TIME-WAIT    |  D3  E  F3 H6
+      -------------+------------------------
+      CLOSED       |  G
+      -------------+------------------------
+
+      For example, in the ESTABLISHED state the arrival of a packet
+      causes procedure C2 to be executed, then D2, then E, F2, H2, and
+      finally I1.  Any procedure may terminate the processing which
+      occurs or cause a state change.  Note that these procedures are
+      executed in sequence, first C2, then D2, etc.  The time ordering
+      cannot be mixed.
+
+      The particular actions associated with each procedure are now
+      described.
+
+
+
+
+
+
+
+
+Finn                                                           [Page 26]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+      A  --------------------------------------------------------
+
+         This procedure details the behavior of the LISTEN state.  First
+         check the packet for the RST flag.  If it is set then packet is
+         discarded and ignored, return and continue the processing
+         associated with this state.
+
+         We assume now that the RST flag was not set.  Check the packet
+         for the ACK flag.  If it is set we have an illegal condition
+         since no connection has yet been opened.  Send a RST packet
+         with the correct response SN value:
+
+            <SN=received AN><CTL=RST>
+
+         Return to the current state without any further processing.
+
+         We assume now that neither the RST nor the ACK flags were set.
+         Check the packet for a SYN flag.  If it is set then an attempt
+         is being made to open a connection.  Create a TCB for this
+         connection.  The sender has placed its MDL in the LENGTH field,
+         also specified is the sender's initial SN value.  Retrieve and
+         place them into the TCB.  Note that the presence of the SO flag
+         is ignored since it has no meaning when either of the SYN, RST,
+         or FIN flags are set.
+
+         Send a SYN packet which acknowledges the SYN received.  Choose
+         the initial SN value and the MDL for this end of the
+         connection:
+
+            <SN=0><AN=received SN+1 modulo 2><CTL=SYN, ACK><LENGTH=MDL>
+
+         and go to the SYN-RECEIVED state without any further
+         processing.
+
+         Any packet not satisfying the above tests is discarded and
+         ignored.  Return to the current state without any further
+         processing.
+
+
+
+
+
+
+
+
+
+
+
+
+Finn                                                           [Page 27]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+      B  --------------------------------------------------------
+
+         This procedure represents the behavior of the SYN-SENT state
+         and is entered when this end of the connection decides to
+         execute an active OPEN.
+
+         First, check the packet for the ACK flag.  If the ACK flag is
+         set then check to see if the AN value was as expected.  If it
+         was continue below.  Otherwise the AN value was unexpected.  If
+         the RST flag was set then discard the packet and return to the
+         current state without any further processing, else send a
+         reset:
+
+            <SN=received AN><CTL=RST>
+
+         Discard the packet and return to the current state without any
+         further processing.
+
+         At this point either the ACK flag was set and the AN value was
+         as expected or ACK was not set.  Second, check the RST flag.
+         If the RST flag is set there are two cases:
+
+            1. If the ACK flag is set then discard the packet, flush the
+            retransmission queue, inform the user "Error: Connection
+            refused", delete the TCB, and go to the CLOSED state without
+            any further processing.
+
+            2. If the ACK flag was not set then discard the packet and
+            return to this state without any further processing.
+
+         At this point we assume the packet contained an ACK which was
+         Ok, or there was no ACK, and there was no RST.  Now check the
+         packet for the SYN flag.  If the ACK flag was set then our SYN
+         has been acknowledged.  Store MDL received in the TCB.  At this
+         point we are technically in the ESTABLISHED state.  Send an
+         acknowledgment packet and any initial data which is queued to
+         send:
+
+            <SN=received AN><AN=received SN+1 modulo 2><CTL=ACK><DATA>
+
+         Go to the ESTABLISHED state without any further processing.
+
+         If the SYN flag was set but the ACK was not set then the other
+         end of the connection has executed an active open also.
+         Acknowledge the SYN, choose your MDL, and send:
+
+            <SN=0><AN=received SN+1 modulo 2><CTL=SYN, ACK><LENGTH=MDL>
+
+
+Finn                                                           [Page 28]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+         Go to the SYN-RECEIVED state without any further processing.
+
+         Any packet not satisfying the above tests is discarded and
+         ignored.  Return to the current state without any further
+         processing.
+
+      C1 --------------------------------------------------------
+
+         Examine the received SN field value.  If the SN value was
+         expected then return and continue the processing associated
+         with this state.
+
+         We now assume the SN value was not what was expected.
+
+         If either RST or FIN were set discard the packet and return to
+         the current state without any further processing.
+
+         If neither RST nor FIN flags were set it is assumed that this
+         packet is a duplicate of one already received.  Send an ACK
+         back:
+
+            <SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
+
+         Discard the duplicate packet and return to the current state
+         without any further processing.
+
+      C2 --------------------------------------------------------
+
+         Examine the received SN field value.  If the SN value was
+         expected then return and continue the processing associated
+         with this state.
+
+         We now assume the SN value was not what was expected.
+
+         If either RST or FIN were set discard the packet and return to
+         the current state without any further processing.
+
+         If SYN was set we assume that the other end crashed and has
+         attempted to open a new connection.  We respond by sending a
+         legal reset:
+
+            <SN=received AN><AN=received SN+1 modulo 2><CTL=RST, ACK>
+
+         This will cause the other end, currently in the SYN-SENT state,
+         to close.  Flush the retransmission queue, inform the user
+         "Error: Connection reset", discard the packet, delete the TCB,
+         and go to the CLOSED state without any further processing.
+
+
+Finn                                                           [Page 29]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+         If neither RST, FIN, nor SYN flags were set it is assumed that
+         this packet is a duplicate of one already received.  Send an
+         ACK back:
+
+            <SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
+
+         Discard the duplicate packet and return to the current state
+         without any further processing.
+
+      D1 --------------------------------------------------------
+
+         The packet is examined for a RST flag.  If RST is not set then
+         return and continue the processing associated with this state.
+
+         RST is now assumed to have been set.  If the connection was
+         originally initiated from the LISTEN state (it was passively
+         opened) then flush the retransmission queue, discard the
+         packet, and go to the LISTEN state without any further
+         processing.
+
+         If instead the connection was initiated actively (came from the
+         SYN-SENT state) then flush the retransmission queue, inform the
+         user "Error: Connection refused", discard the packet, delete
+         the TCB, and go to the CLOSED state without any further
+         processing.
+
+      D2 --------------------------------------------------------
+
+         The packet is examined for a RST flag.  If RST is not set then
+         return and continue the processing associated with this state.
+
+         RST is now assumed to have been set.  Any data remaining to be
+         sent is flushed.  The retransmission queue is flushed, the user
+         is informed "Error: Connection reset.", discard the packet,
+         delete the TCB, and go to the CLOSED state without any further
+         processing.
+
+      D3 --------------------------------------------------------
+
+         The packet is examined for a RST flag.  If RST is not set then
+         return and continue the processing associated with this state.
+
+         RST is now assumed to have been set.  Discard the packet,
+         delete the TCB, and go to the CLOSED state without any further
+         processing.
+
+
+
+
+Finn                                                           [Page 30]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+      E  --------------------------------------------------------
+
+         Check the presence of the SYN flag.  If the SYN flag is not set
+         then return and continue the processing associated with this
+         state.
+
+         We now assume that the SYN flag was set.  The presence of a SYN
+         here is an error.  Flush the retransmission queue, send a legal
+         RST packet.
+
+            If the ACK flag was set then send:
+
+               <SN=received AN><CTL=RST>
+
+            If the ACK flag was not set then send:
+
+               <SN=0><CTL=RST>
+
+         The user should receive the message "Error: Connection reset.",
+         then delete the TCB and go to the CLOSED state without any
+         further processing.
+
+      F1 --------------------------------------------------------
+
+         Check the presence of the ACK flag.  If ACK is not set then
+         discard the packet and return without any further processing.
+
+         We now assume that the ACK flag was set.  If the AN field value
+         was as expected then return and continue the processing
+         associated with this state.
+
+         We now assume that the ACK flag was set and that the AN field
+         value was unexpected.  If the connection was originally
+         initiated from the LISTEN state (it was passively opened) then
+         flush the retransmission queue, discard the packet, and send a
+         legal RST packet:
+
+            <SN=received AN><CTL=RST>
+
+         Then delete the TCB and go to the LISTEN state without any
+         further processing.
+
+         Otherwise the connection was initiated actively (came from the
+         SYN-SENT state) then inform the user "Error: Connection
+         refused", flush the retransmission queue, discard the packet,
+         and send a legal RST packet:
+
+
+
+Finn                                                           [Page 31]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+            <SN=received AN><CTL=RST>
+
+         Then delete the TCB and go to the CLOSED state without any
+         further processing.
+
+      F2 --------------------------------------------------------
+
+         Check the presence of the ACK flag.  If ACK is not set then
+         discard the packet and return without any further processing.
+
+         We now assume that the ACK flag was set.  If the AN field value
+         was as expected then flush the retransmission queue and inform
+         the user with an "Ok" if a buffer has been entirely
+         acknowledged.  Another packet containing data may now be sent.
+         Return and continue the processing associated with this state.
+
+         We now assume that the ACK flag was set and that the AN field
+         value was unexpected.  This is assumed to indicate a duplicate
+         acknowledgment.  It is ignored, return and continue the
+         processing associated with this state.
+
+      F3 --------------------------------------------------------
+
+         Check the presence of the ACK flag.  If ACK is not set then
+         discard the packet and return without any further processing.
+
+         We now assume that the ACK flag was set.  If the AN field value
+         was as expected then continue the processing associated with
+         this state.
+
+         We now assume that the ACK flag was set and that the AN field
+         value was unexpected.  This is ignored, return and continue
+         with the processing associated with this state.
+
+      G  --------------------------------------------------------
+
+         This procedure represents the behavior of the CLOSED state of a
+         connection.  All incoming packets are discarded.  If the packet
+         had the RST flag set take no action.  Otherwise it is necessary
+         to build a RST packet.  Since this end is closed the other end
+         of the connection has incorrect data about the state of the
+         connection and should be so informed.
+
+            If the ACK flag was set then send:
+
+               <SN=received AN><CTL=RST>
+
+
+
+Finn                                                           [Page 32]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+            If the ACK flag was not set then send:
+
+               <SN=0><AN=received SN+1 modulo 2><CTL=RST, ACK>
+
+         After sending the reset packet return to the current state
+         without any further processing.
+
+      H1 --------------------------------------------------------
+
+         Our SYN has been acknowledged.  At this point we are
+         technically in the ESTABLISHED state.  Send any initial data
+         which is queued to send:
+
+            <SN=received AN><AN=received SN+1 modulo 2><CTL=ACK><DATA>
+
+         Go to the ESTABLISHED state and execute procedure I1 to process
+         any data which might be in this packet.
+
+         Any packet not satisfying the above tests is discarded and
+         ignored.  Return to the current state without any further
+         processing.
+
+      H2 --------------------------------------------------------
+
+         Check the presence of the FIN flag.  If FIN is not set then
+         continue the processing associated with this state.
+
+         We now assume that the FIN flag was set.  This means the other
+         end has decided to close the connection.  Flush the
+         retransmission queue.  If any data remains to be sent then
+         inform the user "Warning: Data left unsent."  The user must
+         also be informed "Connection closing."  An acknowledgment for
+         the FIN must be sent which also indicates this end is closing:
+
+            <SN=received AN><AN=received SN + 1 modulo 2><CTL=FIN, ACK>
+
+         Go to the LAST-ACK state without any further processing.
+
+
+
+
+
+
+
+
+
+
+
+
+Finn                                                           [Page 33]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+      H3 --------------------------------------------------------
+
+         This state represents the final behavior of the FIN-WAIT state.
+
+         If the packet did not contain a FIN we assume this packet is a
+         duplicate and that the other end of the connection has not seen
+         the FIN packet we sent earlier.  Rely upon retransmission of
+         our earlier FIN packet to inform the other end of our desire to
+         close.  Discard the packet and return without any further
+         processing.
+
+         At this point we have a packet which should contain a FIN.  By
+         the rules of this protocol an ACK of a FIN requires a FIN, ACK
+         in response and no data.  If the packet contains data we have
+         detected an illegal condition.  Send a reset:
+         <SN=received AN><AN=received SN+1 modulo 2><CTL=RST, ACK>
+
+         Discard the packet, flush the retransmission queue, inform the
+         user "Error: Connection reset.", delete the TCB, and go to the
+         CLOSED state without any further processing.
+
+         We now assume that the FIN flag was set and no data was
+         contained in the packet.  If the AN field value was expected
+         then this packet acknowledges a previously sent FIN packet.
+         The other end of the connection is then also assumed to be
+         closing and expects an acknowledgment.  Send an acknowledgment
+         of the FIN:
+
+            <SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
+
+         Start the 2*SRTT timer associated with the TIME-WAIT state,
+         discard the packet, and go to the TIME-WAIT state without any
+         further processing.
+
+         Otherwise the AN field value was unexpected.  This indicates a
+         simultaneous closing by both sides of the connection.  Send an
+         acknowledgment of the FIN:
+
+            <SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
+
+         Discard the packet, and go to the CLOSING state without any
+         further processing.
+
+
+
+
+
+
+
+Finn                                                           [Page 34]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+      H4 --------------------------------------------------------
+
+         This state represents the final behavior of the LAST-ACK state.
+
+         If the AN field value is expected then this ACK is in response
+         to the FIN, ACK packet recently sent.  This is the final
+         acknowledging message indicating both side's agreement to close
+         the connection.  Discard the packet, flush all queues, delete
+         the TCB, and go to the CLOSED state without any further
+         processing.
+
+         Otherwise the AN field value was unexpected.  Discard the
+         packet and remain in the current state without any further
+         processing.
+
+      H5 --------------------------------------------------------
+
+         This state represents the final behavior of the CLOSING state.
+
+         If the AN field value was expected then this packet
+         acknowledges the FIN packet recently sent.  This is the final
+         acknowledging message indicating both side's agreement to close
+         the connection.  Start the 2*SRTT timer associated with the
+         TIME-WAIT state, discard the packet, and go to the TIME-WAIT
+         state without any further processing.
+
+         Otherwise the AN field value was unexpected.  Discard the
+         packet and remain in the current state without any further
+         processing.
+
+      H6 --------------------------------------------------------
+
+         This state represents the behavior of the TIME-WAIT state.
+         Check the presence of the ACK flag.  If ACK is not set then
+         discard the packet and return without any further processing.
+
+         Check the presence of the FIN flag.  If FIN is not set then
+         discard the packet and return without any further processing.
+
+         We now assume that the FIN flag was set.  This situation
+         indicates that the last acknowledgment of the FIN packet sent
+         by the other end of the connection did not arrive.  Resend the
+         acknowledgment:
+
+            <SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
+
+
+
+
+Finn                                                           [Page 35]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+         Restart the 2*SRTT timer, discard the packet, and remain in the
+         current state without any further processing.
+
+      I1 --------------------------------------------------------
+
+         This represents that stage of processing in the ESTABLISHED
+         state in which all the flag bits have been processed and only
+         data may remain.  The packet is examined to see if it contains
+         data.  If not the packet is now discarded, return to the
+         current state without any further processing.
+
+         We assume the packet contained data, that either the SO flag
+         was set or LENGTH is positive.  That data is placed into the
+         user's receive buffers.  As these become full the user should
+         be informed "Receive buffer full."  An acknowledgment is sent:
+
+            <SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
+
+         If data is queued to send then it is most efficient to
+         'piggyback' this acknowledgment on that data packet.
+
+         The packet is now discarded, return to the ESTABLISHED state
+         without any further processing.
+
+   5.4. Timers
+
+      There are three timers associated with this protocol.  Their
+      purpose will now be briefly discussed as will the actions taken
+      when a timer expires.  The particular nature these timeouts take
+      and the methods by which they are set is the responsibility of the
+      protocol implementation.
+
+      5.4.1. User Timeout
+
+         For practical implementation reasons it is desirable to have a
+         user controllable timeout associated with the successful
+         opening of a connection, successful acknowledgment of data, and
+         successful closing of a connection.  Consider the situations in
+         which a connection is so noisy that no data gets through, or a
+         connection is physically cut.  Without an overriding timeout
+         these situations would result in unbounded retransmissions.
+
+         When this timeout expires the user is informed "Error:
+         Connection aborted due to user timeout.", all queues are
+         flushed, the TCB is deleted, and the CLOSED state is entered.
+
+
+
+
+Finn                                                           [Page 36]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+      5.4.2. Retransmission Timeout
+
+         This timer ensures that any packet sent for which the SN is
+         significant is acknowledged.  When such a packet is sent it is
+         placed in a retransmission queue and the retransmission timer
+         is begun.  If an acknowledgment has not arrived within the
+         timer's period then the packet is retransmitted and the timer
+         is restarted.  If the acknowledgment does arrive in time then
+         the timer is stopped and the packet is removed from the
+         retransmission queue.  The next packet with a significant SN
+         may now be sent.
+
+         This timeout is expected to operate in conjunction with a
+         counter which keeps track of the number of times a packet has
+         been retransmitted.  Normally an upper limit is set on
+         retransmissions.  If that limit is exceeded then the connection
+         is aborted.  This event is similar to the user timeout.  The
+         user is informed "Error: Connection aborted due to
+         retransmission failure", all queues are flushed, the TCB is
+         deleted, and the CLOSED state is entered.
+
+      5.4.3. TIME-WAIT Timeout
+
+         This timeout is used to catch any FIN packets which might be
+         retransmitted from the other end of a connection in response to
+         a dropped acknowledgment packet.  The timeout period should be
+         at least as long as 2*SRTT.  After this timeout expires the
+         other end of the connection is assumed to be closed, the TCB is
+         deleted, and this end enters the CLOSED state also.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finn                                                           [Page 37]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+6. Data Error Handling
+
+   This chapter discusses in detail the types of data errors an
+   established connection may encounter.  These are distinct from
+   protocol errors discussed above.  In order of discussion these are:
+
+      - Framing Errors
+
+      - Missing SYNCH pattern
+
+      - Unacknowledged packets
+
+      - Bad packets
+
+      - Duplicate packets
+
+      - Outside flow control
+
+      - Packets that are too large
+
+      - Packets that are too small
+
+   6.1. Framing Errors
+
+      The RS-232 specification provides framing only for an individual
+      octet.  Link level protocols for computer networking normally
+      provide framing for each packet.  The SYNCH pattern provides a
+      boundary for the beginning of a packet.  No similar pattern was
+      chosen to mark the end and completely frame the packet.
+
+      Any bit pattern can appear in the data portion of a packet.  For
+      any particular pattern to reliably mark the end of a packet that
+      terminating pattern cannot be allowed to appear in the data.  This
+      is usually accomplished by the sender altering any occurrence of
+      the terminating pattern in the data so that it is both no longer
+      recognizable as that pattern and also restorable upon receipt.
+      Both the sender and the receiver are required by this technique to
+      examine all the data.  In the absence of a protocol chip to
+      perform this function, it is a source of some overhead.
+
+      6.1.1. Synthetic Framing
+
+         In the absence of framing, the end of the packet must be
+         synthetically determined.  The start of a packet is indicated
+         by the SYNCH pattern.  The expected end of a packet can now
+         only be determined by examining the LENGTH octet of the header.
+         It is important to know whether or not the LENGTH data can be
+
+
+Finn                                                           [Page 38]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+         trusted.  This is accomplished by employing a one octet header
+         checksum to cover the first two octets following the SYNCH
+         pattern.  If the header passes the checksum test and neither
+         the SYN, FIN, RST, nor SO flag bits were set then LENGTH is
+         trusted and the number of octets expected beyond the header is
+         LENGTH+2. (For those packets in which any of the above flag
+         bits are set the packet length is fixed and includes only a
+         header portion.)
+
+         If the header fails the checksum test we are in some
+         difficulty.  The length is incorrect so it may be too small or
+         too large.  To recover from this error do the following.
+         Beginning immediately after the SYNCH pattern rescan looking
+         for the next SYNCH pattern.  Throw away all octets until a
+         SYNCH is seen and then attempt to reinterpret it as a packet.
+         The sender's retransmission timeout guarantees that a new copy
+         of the packet will be transmitted.  This ensures that in
+         discarding the initial SYNCH pattern, the SYNCH pattern from
+         the beginning of the retransmitted packet will eventually be
+         seen.
+
+      6.1.2. Costs of Synthetic Framing
+
+         This framing strategy causes no overhead unless data errors
+         occur in the packet.  This is presumed to be a low probability
+         occurrence.  In addition it removes the overhead of both sender
+         and receiver passing over the data to process any termination
+         pattern which might appear in the data.
+
+         The worst case behavior would require a packet header to fail
+         its checksum, a new SYNCH pattern to appear in the next few
+         octets, that header failing its checksum, etc., until the SYNCH
+         pattern of the retransmitted packet were finally seen.
+         Consistently bad behavior of this type indicates an extremely
+         noisy communications link.
+
+   6.2. Missing SYNCH Pattern
+
+      Any valid packet must begin with the SYNCH pattern.  Any receiver
+      must discard all input octets until the SYNCH pattern is seen.
+      The data which immediately follows a SYNCH pattern is interpreted
+      as a packet.  The header checksum test is applied, then LENGTH+2
+      octets are read, the data checksum test is applied, etc.
+
+
+
+
+
+
+Finn                                                           [Page 39]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+   6.3. Unacknowledged Packets
+
+      If an ACK for a packet is not obtained within the retransmission
+      timeout interval that packet is retransmitted.  Because
+      significant variability in response can be expected from either
+      end of a connection it is best to dynamically calculate the
+      retransmission timeout interval.  An example of such a calculation
+      is provided below.  The protocol will operate successfully,
+      although not with as high an effective transmission rate, if a
+      realistic upper bound time is used instead.
+
+      A realistic upper bound time depends upon the packet size and line
+      speed.  If the baud rate of the connection is 300 or above let B
+      be the baud rate (for clarity assume it is the same in both
+      directions), let L be the MDL of the receiver, let P be the packet
+      processing time of the receiver.  Then an Upper Bound for the
+      Reception Time (UBRT) is:
+
+         UBRT = L/(B/10) seconds + P seconds
+
+      and a realistic upper bound time is 2*UBRT seconds.
+
+      6.3.1. Calculation of Retransmission Timeout Interval
+
+         For the purpose of detecting retransmission time out the
+         protocol must have access to a clock which provides at least
+         single second resolution.  One technique for calculating the
+         round trip time is:
+
+            Measure the elapsed time between sending a packet with a
+            particular SN and receiving an ACK with an AN which covers
+            that SN.  The measured elapsed time is the Round Trip Time
+            (RTT).  Next a Smoothed Round Trip Time (SRTT) is calculated
+            as:
+
+               SRTT = (ALPHA * SRTT) + ((1- ALPHA) * RTT)
+
+            and based upon this you compute the Retransmission Time Out
+            (RTO) as:
+
+               RTO = min[UBOUND, max[LBOUND, (BETA * SRTT)]]
+
+            where UBOUND is an upper bound on the timeout (e.g., 1
+            minute), LBOUND is a lower bound on the timeout (e.g., 1
+            second), ALPHA is a smoothing factor (e.g., .8 to .9), and
+            BETA is a delay variance factor (e.g., 1.3 to 2.0).
+
+
+
+Finn                                                           [Page 40]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+   6.4. Bad Packets
+
+      A bad packet is received when it fails either the header or data
+      checksum tests.  When this happens the sender will retransmit the
+      packet after the retransmission timeout interval.
+
+   6.5. Duplicate Packets
+
+      A duplicate packet is a packet which passes the checksum tests but
+      for which the SN received is significant but not the expected
+      value.  This is normally caused when the sender did not get the
+      ACK last sent by the receiver.  This situation is diagrammed
+      below.
+
+      Side A                                             Side B
+
+      ESTABLISHED                                        ESTABLISHED
+
+      1.      --> <SN=1><AN=0><CTL=ACK><DATA>       ...
+                                                    -->
+
+      2.      XXX <SN=0><AN=0><CTL=ACK><OTHER-DATA> <--
+
+      3. (after SRTT)
+              --> <SN=1><AN=0><CTL=ACK><DATA>       ...
+
+      4.                                            -->
+              ... <SN=0><AN=0><CTL=ACK><OTHER-DATA> <--
+
+      5.      <--
+
+      In line 2, B's packet was lost in transit, it may have failed its
+      checksum tests when it reached A or its initial SYNCH pattern was
+      smashed, etc..  In line 3 side A comes to the decision that its
+      packet from line 1 was not received after SRTT time passes and
+      retransmits that packet.
+
+      In line 4 side B receives the packet.  It detects a duplicate
+      because it already sent a packet acknowledging A's SN=1 (although
+      that packet was lost).  B now discards the duplicate and
+      immediately retransmits its last packet to A. Side A finally
+      receives the retransmitted packet in line 5.
+
+
+
+
+
+
+
+Finn                                                           [Page 41]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+   6.6. Outside Flow Control
+
+      There are many large computer systems which make use of flow
+      control to regulate their input side of an RS-232 link.  Flow
+      control based upon two special characters such as <Ctrl-S> (ASCII
+      DC3) and <Ctrl-Q> (ASCII DC1) is almost universally in use today.
+      So it becomes important for the protocol to be able to either:
+
+         (1) Recognize and obey the flow control of the host
+             computer(s), or
+
+         (2) Ignore the flow control but still guarantee reliable data
+             reception.
+
+      It is the latter approach which this protocol takes.  This
+      decision was made because the number of differing flow control
+      characters in use would make it difficult to obey them all.
+
+         There is a particular type of flow control with which this
+         protocol will not operate.  The ENQUIRE, ACKNOWLEDGE method of
+         flow control requires that the receiver of an inquiry respond
+         with an acknowledge before any more data will be sent to it.
+         This type of flow control also usually prohibits unrestricted
+         8-bit data transmission because the inquiry character is
+         forbidden as a data byte.
+
+      For the other class of flow control methods a proof is required
+      that data may still be reliably transmitted and received if flow
+      control is ignored.  For the purposes of this discussion assume
+      <Ctrl-S> is sent when the receiving end of the connection wishes
+      the sender to stop transmitting.  A <Ctrl-Q> is sent when the
+      receiver wishes the sender to resume.  The choice of these
+      particular two characters is arbitrary.  If the sender does not
+      immediately cease transmission upon receipt of the <Ctrl-S>,
+      characters may be discarded.  Since this protocol chooses to
+      ignore the flow control characters any part of a packet may be
+      discarded.
+
+      More precisely stated consider X to be the receiver and Y to be
+      the sender.  The packet sent is represented by the string abc
+      where a, b, and c are data segments of unspecified size.  X may
+      receive one of:
+
+         1. abc
+         2. ab
+         3. ac
+         4. bc
+
+
+Finn                                                           [Page 42]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+      For case [1] the correct data is received and no special action
+      need be taken.
+
+      For cases [2], [3], and [4] we have a situation identical to data
+      dropped during transmission.  This is handled by the same
+      checksum, time-out and retransmission strategy already described.
+
+      Assume Y is not now in the act of receiving a packet, then Y sees
+      the two characters <Ctrl-S> and <Ctrl-Q> appear as input in that
+      order.  Y is waiting for a message to appear and so expects to see
+      a SYNCH pattern.  If the two characters "<Ctrl-S><Ctrl-Q>" are not
+      part of a SYNCH pattern then they will be immediately discarded.
+      If Y is receiving a packet then the <Ctrl-S> and <Ctrl-Q> are seen
+      to be added noise characters and would be detected by the checksum
+      tests.  The packet being received would require retransmission.
+
+      The question of which character to pick for the SYNCH pattern is
+      slightly muddied by the above observation.  To the author's
+      knowledge <SOH> is rarely if ever picked for flow control.  This
+      is part of the motivation in using it as the SYNCH pattern.
+
+      How does one guarantee that any data will actually arrive
+      successfully?  The initial choice of maximum data counts during
+      connection establishment is very important.  Some knowledge of
+      one's own operating system must be assumed.  If it is known for
+      example, that streams of data in excess of a certain length will
+      often trigger flow control at the connection baud rate, then the
+      maximum data count should be chosen sufficiently lower that flow
+      control rarely will be employed.  An intelligent choice of the
+      maximum data count will guarantee that some packets will arrive
+      without encountering flow control.
+
+   6.7. Packets that are too Large
+
+      Assume a packet arrives which passes its header checksum test but
+      whose LENGTH is larger than the MDL of the receiver.  In such a
+      case the sender has violated the protocol or a packet has a data
+      error in the LENGTH octet and has passed the header checksum test.
+      The latter is unlikely so that we assume the former.  The receiver
+      will abort his connection.  The sender must inform the user
+      "Error: Connection aborted due to MDL error", and go to the CLOSED
+      state.
+
+      When the MDL is exceeded the receiver will transmit a legal reset:
+
+         <SN=received AN><CTL=RST>
+
+
+
+Finn                                                           [Page 43]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+   6.8. Packets that are too Small
+
+      Assume that a packet has passed its header checksum test but some
+      of the data octets have been dropped by the link.  In such a case
+      the receiver's routine which reads data and builds packets is
+      expecting octets which do not arrive.  After SRTT the sender will
+      retransmit this packet to the receiver.  The receiver will now
+      have enough data to complete the packet.  Almost certainly however
+      it will fail the data checksum test.  As with any bad packet the
+      receiver will rescan from the octet immediately following the
+      SYNCH pattern for the next SYNCH pattern.  In this manner the
+      receiver will eventually see the SYNCH pattern of the
+      retransmitted packet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finn                                                           [Page 44]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+I.  Inability to Transmit/Receive 8-bit Data
+
+   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.  Where this is an unavoidable problem
+   both ends of the connection must have a protocol layer beneath this
+   protocol.  This lower layer will unpack packets it sends over the
+   RS-232 link.  It will also repack packets it receives over the RS-232
+   link.  RATP will automatically determine whether or not full 8-bit or
+   restricted 7-bit communication is being used (see below).
+
+   The strategy chosen for restricted 7-bit communication is called 4/8
+   packing.  That is, each octet to be sent will be broken up into two
+   4-bit nibbles.  The order of transmission is the high order four bits
+   followed by the low order bits.  Each octet to be received will be
+   repacked by the inverse function.  The high order nibble will be
+   received first then the low order nibble.  These two nibbles will be
+   reassembled into an octet.
+
+   I.1.  Encoding for Transmission
+
+      For those systems which are incapable of 8-bit data transmission
+      over RS-232 links, there are operating systems which in addition
+      place special restrictions on the non-printable ASCII characters.
+      The encoding for 4/8 packing should restrict itself to
+      transmitting data only in the printable 7-bit ASCII range.
+
+   I.2.  Framing an Octet
+
+      The seventh and highest order bit of a transmitted 7-bit ASCII
+      byte is a flag used to indicate whether the high or low order
+      nibble of an octet is contained in this character.  This flag bit
+      if set implies that a new octet is being received and that this
+      printable ASCII character contains the high order nibble of an
+      octet in its four low order bits.  In addition it implies the next
+      ASCII character received should not have its highest order bit
+      set.
+
+      This high order flag bit is set by adding the ASCII character "@"
+      (octal 100) to a data byte.  Thus the first nibble of an octet is
+      always transmitted with "@" added to its value.  The high order
+      nibble will be transformed into the characters "@" through letter
+      "O".
+
+      The lower order nibble of an octet is transmitted with zero "0"
+      added to its value.  The low order nibble will be transformed into
+
+
+
+Finn                                                           [Page 45]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+      characters "0" through "?".  When receiving 4/8 packed data, any
+      characters not within the range "0" through letter "O" are
+      discarded.
+
+      The octet whose octal value is 45 will be transmitted as two 7-bit
+      printable ASCII characters:
+
+                 +-------------+
+      High order |1|0|0|0|1|0|0| First transmitted ("@" + data) = D
+                 +-------------+
+      Low order  |0|1|1|0|1|0|1| Second transmitted ("0" + data) = 5
+                 +-------------+
+
+      Since data bytes may be dropped or added at any time it is
+      important to know always which portion of an octet is expected and
+      to deliver only complete octets to the higher protocol level.  If
+      a single 7-bit character were completely dropped without being
+      noticed the data stream delivered to the higher level could be
+      shifted by an odd multiple of four bits.  In the worst case this
+      condition could remain indefinitely and the higher level would
+      never receive an octet correctly.  In such a case no packets would
+      be correctly received, leading to an unusable connection.
+
+      To avoid this problem octets are assembled using a state machine
+      driven by the presence of the high order flag bit.  The presence
+      of that bit in the 7-bit printable character indicates the
+      beginning of a new octet.  The two state machine which assembles
+      octets is described below.  A byte received with the high order
+      flag bit set is called "HIGH", the byte without "LOW".
+
+         State 0
+
+            [Start state] Read a byte from the legal restricted set.
+            This is determined by seeing if the byte is in the legal
+            range "@" to the letter "O".  If it was not discard the byte
+            and return to this state.
+
+            A HIGH byte was read.  Place the four low order bits of the
+            byte into the four high order bits of the assembled octet
+            and go to state 1.  Otherwise discard the byte and return to
+            this state.
+
+
+
+
+
+
+
+
+Finn                                                           [Page 46]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+         State 1
+
+            Read a byte from the legal restricted set.  This is
+            determined by seeing if the byte is in the legal range zero
+            "0" to the letter "O".  If it was not discard the byte and
+            return to this state.
+
+            If a LOW byte was read subtract zero "0" from the byte
+            placing the four low order bits of the result into the four
+            low order bits of the assembled octet.  A full octet has now
+            been assembled.  Pass the octet to the higher level and go
+            to state 0.
+
+            Otherwise a HIGH byte was read.  Place the four low order
+            bits of the byte into the four high order bits of the
+            assembled octet and return to this state.
+
+      Utilizing this state machine to receive 4/8 packed data ensures
+      that the data stream delivered to the higher level will not
+      permanently remain shifted an odd multiple of four bits.  The
+      restriction placed upon bytes read removes obviously bad data and
+      in some cases would handle uncontrolled padding or blocking
+      insertion.
+
+   I.3.  Automatic Detection of 8-bit or 4/8 Packed Data
+
+      It is an unavoidable problem that some machines cannot handle
+      unrestricted 8-bit data.  Since this is given, it is desirable to
+      be able to automatically detect whether unrestricted 8-bit or
+      restricted 4/8 packing is being used to transmit data on a
+      connection.  For the purposes of this discussion those machines
+      capable of transmitting and receiving both unrestricted 8-bit and
+      4/8 packed data are called smart.  Machines are called dumb if
+      they can only transmit and receive 4/8 packed data.
+
+      When initiating a connection there are four possible machine
+      configurations and they are:
+
+         1. A (smart) opens a connection to B (smart).
+
+         2. A (dumb) opens a connection to B (smart).
+
+         3. A (dumb) opens a connection to B (dumb).
+
+         4. A (smart) opens a connection to B (dumb).
+
+
+
+
+Finn                                                           [Page 47]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+      Each case is examined and extensions to the behavior for the
+      LISTEN and SYN-SENT states are provided which allow both types of
+      machines to initiate or receive a connection.
+
+      Cases 1 and 2: LISTEN Behavior for a Smart Machine
+
+         In these cases machine A initiates a connection to B who is
+         assumed to be in the LISTEN state.  B must be able to passively
+         detect whether 8-bit or 4/8 packing is being used and respond
+         accordingly.  The method B uses relies upon the detection of a
+         valid first packet.  In the LISTEN state B attempts to
+         simultaneously treat the incoming data as if it were both
+         unrestricted 8-bit and 4/8 packed.
+
+         The incoming data is in effect fed to two different receiving
+         algorithms.  The detection of a valid header will occur to one
+         of these algorithms before the other.  If the first valid
+         header was read assuming unrestricted 8-bit data then any
+         resulting connection is assumed to use unrestricted 8-bit data
+         for the life of the connection.  If the first valid header
+         assumed 4/8 packing then the resulting connection is assumed to
+         use 4/8 packing for the life of the connection.  In the case of
+         the detection of illegal condition in the LISTEN state the
+         protocol will reply with a RST packet in kind.
+
+      Case 3: LISTEN Behavior for a Dumb Machine
+
+         In this case machine B is the recipient of a connection request
+         and is capable of handling only 4/8 packed data.  The LISTEN
+         behavior for machine B assumes that all connections are 4/8
+         packed.  It never deals with unrestricted 8-bit data.  As a
+         result it will refuse to open a connection request from a smart
+         machine (see case 4 below).
+
+      Case 4: SYN-SENT Behavior for a Smart Machine
+
+         In this case machine A attempts to open a connection to machine
+         B. However, A has no knowledge of B's capabilities.  A will
+         send its connection request assuming B is smart using
+         unrestricted 8-bit transmission.  It will await a reply
+         assuming the response will be unrestricted 8-bit also.  If B is
+         in fact dumb it will not return a SYN-ACK because of the
+         restriction imposed by case 3 above.  If no connection is made
+         with B using 8-bit data the entire connection initiation is
+         restarted assuming B is dumb, 4/8 packing is used and the
+         response is assumed to be 4/8 packed as well.
+
+
+
+Finn                                                           [Page 48]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+         The cost of this approach is a longer time to determine whether
+         or not it is possible to open a connection to B. It is twice as
+         long.  The advantages of being able to automatically adjust to
+         either unrestricted 8-bit or 4/8 packed data out weigh this
+         disadvantage.  RATP will not exhibit the schizophrenic behavior
+         of many other asynchronous protocols when dealing with both
+         classes of machines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finn                                                           [Page 49]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+II.  A Brief Survey of Some Asynchronous Link Protocols
+
+   II.1.  DDCMP
+
+      DDCMP, Copyright (c) 1978 Digital Equipment Corporation [DDCMP
+      78], is a reliable point-to-point and multi-point transmission
+      protocol is used by many of that manufacturer's computers.  DDCMP
+      does provide reliable asynchronous two way data transmission.
+
+      Some of the decisions taken in the design of DDCMP reflect its
+      orientation toward multi-point data links.  This leads to headers
+      which are substantially longer than needed for two way
+      point-to-point communications.
+
+      DDCMP allows as many as 255 outstanding unacknowledged messages.
+      DDCMP does specifically mention that a particular end of a
+      connection may choose to limit the send queue to one outstanding
+      unacknowledged message.  It also allows sending a stream of
+      outstanding unacknowledged packets.  Unless all RS-232
+      implementations of DDCMP were limited to a single outstanding
+      packet, the collision with existing flow control restrictions
+      could lead to very low thruput. (DDCMP is assumed to have control
+      over the link driver.  Dealing with various differing flow control
+      mechanisms is not a consideration.)
+
+      DDCMP uses a CRC polynomial for data protection which is difficult
+      to calculate for many machines without special hardware [TCP
+      Checksum 78].  Many Digital Equipment computers have such
+      hardware.
+
+      DDCMP does not provide the receiver with the ability to restrict
+      incoming packet size.  It is true that all the higher level
+      protocols built on top of DDCMP could separately negotiate packet
+      size.  But this burden would then be moved away from the link
+      level where it properly resides.
+
+      Generally, a full implementation of DDCMP is too complex for
+      consideration.  If one were to implement 'part' of the protocol
+      then issues of compatibility with already existing implementations
+      on other computers are raised.
+
+
+
+
+
+
+
+
+
+Finn                                                           [Page 50]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+   II.2.  MODEM Protocol
+
+      This is a protocol in common use amongst microcomputers.  The
+      description here comes from
+
+         MODEM/XMODEM Protocol Explained by Kelly Smith, CP/M-Net
+         "SYSOP" January 8,1980
+
+         .... Data is sent in 128-byte sequentially numbered blocks,
+         with a single checksum byte appended to the end of each block.
+         As the receiving computer acquires the incoming data, it
+         performs its own checksum and upon each completion of a block,
+         it compares its checksum result with that of the sending
+         computers.  If the receiving computer matches the checksum of
+         the sending computer, it transmits an ACK (ASCII code protocol
+         character for ACKNOWLEDGE (06 Hex, Control-F)) back to the
+         sending computer.  The ACK therefore means "all's well on this
+         end, send some more...".
+
+         The sending computer will transmit an "initial NAK" (ASCII
+         protocol character for NEGATIVE ACKNOWLEDGE (15 Hex,
+         Control-U))...or, "that wasn't quite right, please send again".
+         Due to the asynchronous nature of the initial "hook-up" between
+         the two computers, the receiving computer will "time-out"
+         looking for data, and send the NAK as the "cue" for the sending
+         computer to begin transmission.  The sending computer knows
+         that the receiving computer will "time-out", and uses this fact
+         to "get in sync"...  The sending computer responds to the
+         "initial NAK" with a SOH (ASCII code protocol character for
+         START OF HEADING (01 Hex, Control-A)), sends the first block
+         number, sends the 1's complement of the block number, sends 128
+         bytes of 8 bit data, and finally a checksum, where the checksum
+         is calculated by summing the SOH, the block number, the block
+         number 1's complement, and the 128 bytes of data.
+
+         Receiving Computer:
+
+            ---/NAK/------------------------/ACK/------------------
+                15H                          06H
+
+         Sending Computer:
+
+            ---/SOH/BLK#/BLK#/DATA/CSUM/---/SOH/BLK#/BLK#/DATA/etc.
+                01H 01H  FEH  8bit 8bit     01H 02H  FDH  8bit ....
+
+
+
+
+
+Finn                                                           [Page 51]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+         This process continues, with the next 128 bytes.  If the block
+         was ACK'ed by the receiving computer, and then the next
+         sequential block number and its 1's complement, etc. ....
+
+      As can be seen from this partial description the MODEM protocol is
+      unidirectional, data can only pass from the sender to the receiver
+      in a stream.  In order for data to flow simultaneously in the
+      other direction another connection over another RS-232 line would
+      be required.
+
+      In addition this protocol is restricted to a fixed 128 octet
+      packet size.  Many front-end concentrators are unable to service
+      such large incoming packets.  It has been observed many times that
+      the concentrator of a busy DECsystem-20 can invoke flow control on
+      input at 1200 baud for packets as small as 64 characters.
+
+   II.3.  KERMIT System
+
+      The KERMIT system, Copyright (c) 1981 Columbia University, is a
+      file transfer environment developed recently.  It has
+      implementations which run on DECsystem-20, IBM 370 VM/CMS, 8080
+      CP/M based systems, and the IBM PC among others.
+
+      KERMIT combines both the reliable transfer and file transfer into
+      a single package.  Extension to other applications and higher
+      level protocols would be possible but the boundary between the
+      reliable transfer and application layers is very indistinct.  It
+      violates the layering design strategy the Internet employs.
+
+      There is a limitation of transmission to the restricted printable
+      ASCII set for certain computers but not for others.  This leads to
+      confusion.  KERMIT allows both restricted ASCII and 8-bit
+      transmission.
+
+      The KERMIT protocol does have a method of setting MDL at
+      connection initiation.  It is limited to a smaller maximum packet
+      size, 96 as opposed to 261 octets.  Kermit originally used a
+      checksumming algorithm limited to six bits.  This is considered to
+      provide too low a level of error detection capability for data
+      packets.  Kermit now allows two other checksumming algorithms in
+      addition to the original.  There must be a negotiation between
+      sender and receiver regarding which algorithm to use.
+
+      The KERMIT protocol does not appear to make provision for both
+      sides of a connection attempting an active open simultaneously.
+      One side must be an initial "sending Kermit" and the other a
+      "receiving Kermit".  The code published as a KERMIT implementation
+
+
+Finn                                                           [Page 52]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+      guide cannot recover from simultaneous active opens, it
+      immediately ABORTs.  This reflects a bias towards unidirectional
+      data flow.
+
+      The KERMIT packet type (similar to RATP control flags) specifies
+      whether an ACK/NAK is contained in the packet, or data, etc.
+      These are mutually exclusive and piggybacking an ACK on a data
+      packet is not possible.  This can be a source of overhead.  In
+      addition KERMIT restricts the sender to a single outstanding
+      unacknowledged packet as does RATP.  It allocates an entire byte
+      to the sequence number which is unnecessary.
+
+      On the subject of error recovery, the size of a packet is
+      contained in the second byte of the packet and is not protected by
+      a header checksum.  If the length field was in error due to noise
+      on the link, it could be longer than the correct packet size.  The
+      code published as the KERMIT implementation guide relies upon the
+      detection of the <SOH> character anywhere in a packet to indicate
+      the beginning of a packet header.  It re-SYNCHs using this
+      technique.  This is only possible if binary data in a packet is
+      quoted.  If full eight bit data is transmitted it does not appear
+      that the KERMIT protocol rescans for a new MARK (SYNCH) character
+      within the bad packet data just consumed.  It will under these
+      circumstances throw away the retransmitted packet or portions
+      thereof.  Re-SYNCHing under such conditions is problematical.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finn                                                           [Page 53]
+
+
+
+RFC 916                                                     October 1984
+Reliable Asynchronous Transfer Protocol
+
+
+REFERENCES
+
+   [Cohen 81]
+
+      Cohen, D. On Holy Wars and a Plea for Peace. IEEE Computer,
+      October, 1981.
+
+   [DDCMP 78]
+
+      DDCMP AA-D599A-TC edition, Digital Equipment Corporation, 1978.
+      Version 4.0.
+
+   [IP 81]
+
+      Postel, J. DOD Standard Internet Protocol [RFC-791] Defense
+      Advanced Research Projects Agency, 1981.
+
+   [TCP 81]
+
+      Postel, J. Transmission Control Protocol [RFC-793] Defense
+      Advanced Research Projects Agency, 1981.
+
+   [TCP Checksum 78]
+
+      Plummer, W. W. TCP Checksum Function Design. Technical Report,
+      Bolt Beranek and Newman, Inc., 1978.
+
+EDITORS NOTES
+
+   This memo was prepared in essentially this form in June 1983, and set
+   aside.  Distribution at this time is prompted by the the "Thinwire"
+   proposal described in RFC-914.
+
+   --jon postel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finn                                                           [Page 54]
+