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 DBDC 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