Serial line Framing Protocol

 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.