153 lines
7.1 KiB
Plaintext
153 lines
7.1 KiB
Plaintext
1 MNET:MIT.SLFP Last updated: 10 November 1987
|
|
|
|
This file contains technical documentation of the MIT Serial Line
|
|
Framing Protocol, as implemented in the Merit Computer Network.
|
|
It was retyped from the original information from MIT on 11/10/87.
|
|
|
|
Appendix I: Serial line Framing Protocol
|
|
|
|
(This description is from a very old file written when we
|
|
were first implementing the protocol. Details are still
|
|
accurate, though.)
|
|
|
|
This is preliminary documentation on the serial line
|
|
protocol used between the IBM PCs and the PC Gateway. The
|
|
protocol has two levels: the low-level protocol (LLP) and the
|
|
local net protocol. The low level protocol wraps a packet and
|
|
delivers it to the PC Gateway. The local net protocol tells the
|
|
PC Gateway what kind of packet it is. Currently there two types
|
|
of packets: Internet and Address Request. When the PC Gateway
|
|
receives an Internet packet, its action is to forward the
|
|
internet packet to a process which checks the packet for
|
|
validity and then sends it to the net. On receipt of an Address
|
|
Request packet, the PC Gateway sends an Address Request packet
|
|
back to the PC with four bytes of data (the PC's internet
|
|
address) in the body of the packet.
|
|
|
|
Neither the LLP nor the local net protocol provide for
|
|
prioritized transmissions, checksums or complex line control.
|
|
They are merely a simple way to get packets to and from
|
|
machines.
|
|
|
|
The local net protocol consists of a four byte leader. For
|
|
an internet packet, this leader is: 2,1,0.0. For an Address
|
|
Request, the leader is 2,3,0.0. There is no data in the Address
|
|
Request packet sent from the PC; it is only the four byte local
|
|
net header wrapped in the serial line protocol.
|
|
|
|
The receipt of any packet with a local net header that does
|
|
not identify the packet as either internet or address request is
|
|
an error and the receipt of such a packet should be logged and
|
|
the packet discarded.
|
|
|
|
LLP consists of four bytes with special meanings when
|
|
received over the serial line. These are: ESC, REQ, ACK, and
|
|
END.
|
|
|
|
A packet is enclosed in a REQ and an END. When a PC wishes
|
|
to send a packet it first sends a REQ to the PC Gateway. It
|
|
then waits a suitable length of time to receive an ACK from the
|
|
PC Gateway. If no ACK byte is received, the PC Gateway is
|
|
assumed to be unable to handle the packet right now and a
|
|
timeout is said to have occurred. The PC may either retry, wait
|
|
or return an error.
|
|
|
|
After the PC receives the ACK signal, it may begin sending
|
|
the packet. The first four bytes of the packet should be the
|
|
local net header and an error will occur if they are not valid.
|
|
When the PC has completed sending the packet, it should send an
|
|
END byte to the Gateway. The PC gateway will then consider the
|
|
packet and act upon it.
|
|
1 2
|
|
|
|
|
|
The PC Gateway goes through a similar process when it sends
|
|
a packet to a PC; only the roles are reversed. It is an error
|
|
for the PC Gateway to send a PC its address if the PC has not
|
|
requested its address from the Gateway.
|
|
|
|
If a machine should receive a REQ embedded in a packet,
|
|
this indicates that the END signal was dropped somewhere. The
|
|
receiving machine should drop the packet it was receiving and
|
|
begin to receive a new one. ACKs may be mixed inside packets to
|
|
allow immediate response to REQs. The receipt of an ACK by a
|
|
machine should be duly logged (and perhaps appropriately ignored
|
|
if the PC doesn't have an outstanding request).
|
|
|
|
The final code, ESC, is used to allow the characters whose
|
|
codes are used by ESC, REQ, ACK and END to appear in packets.
|
|
Receiving an ESC indicates that the next byte should be looked
|
|
at to produce the correct character. Here is a table of the
|
|
codes for the signals and the ESC sequences to produce the data
|
|
whose codes they use.
|
|
|
|
ESC 242 ESC 0
|
|
REQ 243 ESC 1
|
|
ACK 244 ESC 2
|
|
END 245 ESC 3
|
|
|
|
A simple way to unstuff the bytes is to add the character
|
|
following an ESC to the ESC to get the correct code and then put
|
|
it in the packet as data. It is an error to have any character
|
|
>3 follow an ESC.
|
|
|
|
If a machine receives any character other than a REQ or an
|
|
ACK when it is not in the process of receiving a packet, it
|
|
should discard that character.
|
|
|
|
Low-level protocol specification: IBM to Gateway, Gateway
|
|
to IBM.
|
|
|
|
The following ASCII codes are used as flags in the manner
|
|
specified:
|
|
|
|
242 - Prefix code for sending data codes which are set
|
|
aside for protocol use.
|
|
243 - Request to send (REQ).
|
|
244 - Acknowledge (ACK).
|
|
245 - End of packet (END).
|
|
|
|
A typical data transfer occurs as follows:
|
|
|
|
|
|
IBM wants to send packet to Gateway: It sends REQ and waits for ACK.
|
|
Gateway is ready to receive packet: It sends ACK
|
|
IBM sends packet to Gateway followed by END.
|
|
The packet itself is encoded so that REQ, ACK, and END never
|
|
appear in the text. This is done by performing the following
|
|
substitutions:
|
|
1 3
|
|
|
|
|
|
242 --> 242 0
|
|
243 --> 242 1
|
|
244 --> 242 2
|
|
245 --> 242 3
|
|
|
|
Note that transfers can occur in both directions
|
|
simultaneously. However the ACK signal may be embedded within a
|
|
data packet and must be explicitly removed:
|
|
|
|
IBM wants to send packet to Gateway: It sends REQ and waits for ACK.
|
|
Gateway is ready to receive packet: It sends ACK.
|
|
IBM starts sending packet.
|
|
Gateway wants to send packet to IBM: It sends REQ and waits for ACK.
|
|
IBM is ready to receive packet: It sends ACK.
|
|
IBM continues sending its packet, while Gateway sends a packet to
|
|
IBM.
|
|
|
|
Timeouts may occur if the wait between a REQ and an ACK is
|
|
too long or no packet characters are transmitted for too long a
|
|
time. In both cases no recovery action is undertaken: the other
|
|
system is assumed to have crashed.
|
|
|
|
Receipt of protocol codes within a data packet has the
|
|
following consequences:
|
|
|
|
REQ - End portion of data packet being sent has been lost.
|
|
ACK - Should be removed from input packet and its presence
|
|
logged for use by the process which is sending
|
|
characters.
|
|
END - Packet has been completely sent.
|
|
|