Re: SLIP Info please?

Phil R. Karn (thumper!
1 Jun 88 19:55:34 GMT

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:

<Frame End> C0 hex
<Frame Esc> DB
<Transposed Frame End> DC
<Transposed Frame Esc> DD

Transmitter Operation

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

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 <Frame
End> character. (The <Frame End> itself is not added to the buffer). The
receiver maintains a one-bit "escaped" flag that is set whenever it sees
a <Frame Esc> character. (The <Frame Esc> character itself is NOT added
to the reassembly buffer). If the receiver then sees either a
<Transposed Frame End> or a <Transposed Frame Esc> while in "escaped"
mode, it is translated to a <Frame End> or a <Frame Esc>, respectively,
and adds it to the reassembly buffer. Regardless of the character
received while in escaped mode, the "escaped" flag is cleared. If the
<Transposed Frame End> or <Transposed Frame Esc> characters are received
while NOT in "escaped" mode, no special action is necessary; they are
added to the reassembly buffer unchanged.

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

The original SLIP put <Frame End> characters only at the end of each
frame. I.e., a series of back-to-back frames would be separated by only
a single <Frame End>. I have made a minor, backward compatible change to
the protocol that puts a <Frame End> in front of each frame as well.
This adds a very small bit of overhead (back-to-back frames are now
separated by two <Frame End> 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


This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:42:29 GMT