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.

