Xref: utzoo rec.ham-radio.packet:1173 comp.protocols.tcp-ip:3705
Path: utzoo!attcan2!uunet!husc6!bloom-beacon!mit-eddie!rutgers!bellcore!faline!thumper!karn
From: karn@thumper.bellcore.com (Phil R. Karn)
Newsgroups: rec.ham-radio.packet,comp.protocols.tcp-ip
Subject: Re: SLIP Info please?
Summary: SLIP definition
Message-ID: <1115@thumper.bellcore.com>
Date: 1 Jun 88 19:55:34 GMT
References: <401@jc3b21.UUCP>
Organization: Bell Communications Research, Inc
Lines: 63

I don't think I've seen a formal description of SLIP, but it is very
simple.  It is just a framing technique suitable for carrying IP
datagrams (or whatever you want) on asynchronous links.

Four special characters are defined. They are as follows:

		C0 hex
		DB
	DC
	DD

Transmitter Operation

The transmitter sends the frame a byte at a time, ending it with the
 character. If a  character occurs in the body of
the frame, it is replaced by the two character sequence ,
. Similarly, if a  character occurs in
the body of the frame, it is replaced by the two byte sequence , .

Receiver Operation

The receiver appends incoming bytes to a reassembly buffer, passing 
whatever has been accumulated up to the next layer when it sees a  character. (The  itself is not added to the buffer). The
receiver maintains a one-bit "escaped" flag that is set whenever it sees
a  character.  (The  character itself is NOT added
to the reassembly buffer). If the receiver then sees either a
 or a  while in "escaped"
mode, it is translated to a  or a , respectively,
and adds it to the reassembly buffer. Regardless of the character
received while in escaped mode, the "escaped" flag is cleared. If the
 or  characters are received
while NOT in "escaped" mode, no special action is necessary; they are
added to the reassembly buffer unchanged.

Note that the  character is *never* sent over the line except
as an actual end-of-frame indication.

The original SLIP put  characters only at the end of each
frame.  I.e., a series of back-to-back frames would be separated by only
a single . I have made a minor, backward compatible change to
the protocol that puts a  in front of each frame as well.
This adds a very small bit of overhead (back-to-back frames are now
separated by two  characters) but it improves performance
over noisy links by forcing the receiver into a known state at the
beginning of each new frame.

When used to send IP datagrams over phone lines, the datagrams are
encapsulated directly in frames formatted as described here; no
additional header is carried. There has been considerable discussion
about the need for such a header, but nothing has actually come into
use, as far as I know.

I use SLIP in a different way between a system running my TCP/IP
software and a KISS TNC. There I use SLIP style framing to carry AX.25
frames and control messages between the TNC and host, and there is a
one-byte "type" field at the beginning of each frame. For details, see
the paper by K3MC and myself in last year's ARRL Computer Networking
Conference proceedings. (The same article also described SLIP in
detail).

Phil