<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.
RFC916 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.
RFC916 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:
RFC916 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>
RFC916 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.
RFC916 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.
RFC916 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>
RFC916 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.
RFC916 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.
RFC916 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
RFC916 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.
RFC916 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).
RFC916 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.
RFC916 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
RFC916 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>
RFC916 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.
RFC916 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
RFC916 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.
RFC916 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).
RFC916 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.
RFC916 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.
RFC916 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.
RFC916 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 ....
RFC916 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
RFC916 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.
RFC916 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