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.