jra@jc3b21.UUCP (Jay R. Ashworth) (06/01/88)
Can anybody email me more details about SLIP (Serial Link Internet Protocol)? I am interested in the possibility of supporting multiple telnet type login sessions on one physical radio channel, using a standard, albeit high speed (38.4Kb?) serial line between TNC and computer. Does KA9Q do this? Are other possible sources PD? I need to have source code available. I (read: my employer) would be interested in discussing commercial licensing at some future point. For now, though, folks, I'd just like to know what I'm talking about. Can you help? Email ONLY, please. The .sig path should work just fine. Tnx, -- jra KA1FJX -- Jay R. Ashworth ---+-- Suncoast Television Productions--+ ...!uunet!codas! 10974 111th St. N. | producers of Suncoast Magazine | !usfvax2!jc3b21!jra Seminole FL 34648 +------------------------------------------------+--------- (813) 397-1859 ----+-- Premiering on Vision Cable Ch. 24 in July ---+ :-) !$ Robert Heinlein, 1901-1988, alas, not as long-lived as Lazarus Long. R. I. P.
karn@thumper.bellcore.com (Phil R. Karn) (06/02/88)
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 detail). Phil