Re: SLIP (what & where??)


Dennis.Bednar (pitstop!sundc!rlgvax!dennis@sun.com)
25 Feb 88 00:56:47 GMT


In article <3805@galbp.LBP.HARRIS.COM>, gja@galbp.LBP.HARRIS.COM (Greg Ansley) writes:
>
> A need a discription of SLIP, what it is and what it can do as well as
> a pointer to where I can get the code!
> Please reply be mail so as not to bore the rest of the net!

I prefer to bore the net. Here's what I know:

SLIP = Serial Line Internet Protocol

IP packets are sent over an RS-232C serial wire encapsulated
and decapsulated according to the packet formatting rules.
There is no packet header, and only a single byte for the
packet trailer. Since the byte used for the packet trailer
could appear as data in the packet, certain escape conventions
are used to prevent this possiblity. The sending side adds
extra escape prefix characters while sending a packet, and
the receiving side removes the extra escape chars and stores
the unencoded packet for further processing.

SLIP is just another oe of the possible lowest level protocols
between TCP/IP and the raw hardware. SLIP is at the same level
as ethernet/ARP, or an 1822 "bit-banger" protocol, or the newer
DDN X.25 (I think levels 3 and 2) interface.

Historically, as I know it, SLIP was invented by 3com Corp. when
Bruce Borden et.al. developed a TCP/IP package known as UNET.
But it might have been invented at Ford Aerospace, because the
comments in the source code indicated that Ford had some role
as far as helping 3com with some of the software.
Above 4 years ago, Rick Adams worked here at CCI, and ported
UNET to a CCI 5/20 processor running Unix S3. We required
communications between our VAX 780 and the 5/20, and at that
time, the VAX only supported TCP/IP/ethernet, but not SLIP,
and the 5/20 only supported SLIP, but not ethernet. So Rick
Adams wrote the first SLIP driver for the 4.2BSD kernel that
allowed TCP/IP communication between our 4.2BSD VAX and our
S3 5/20. End of story.

As for the packet format, TCP/IP packets are sent "serially",
one-byte-at a time, left-to-right, high-order to low-order
as you might expect if you look at the IP or TCP specs.
The following encoding rules apply (below is the output of
a dumb program called "unetchars" which I wrote several
years ago): I wrote it to document the packet format when we had
to understand and analyze protocol problems seen on a Data
Line Monitor:

                How IP Packets are Sent over an Asynchronous Line

        +------------+--------------------------------------------+-------------+
        | LNI header | LNI (Local Network Interface) data | LNI Trailer |
        +------------+-----------+------------+-------------------+-------------+
                     | IP header | TCP header | optional TCP data |
                     +-----------+------------+-------------------+

                     |<------------ Data Encoding Rules --------->|

                        Special Octets Used For Data Encoding

         Name Hex Octal Decimal Description
        FRMEND 0xc0 0300 192 Frame End Character
        FRMESC 0xdb 0333 219 Frame Escape Character
        M_FRMEND 0xdc 0334 220 Meta Frame End Character
        M_FRMESC 0xdd 0335 221 Meta Frame Escape Character

        There is no LNI header for an asynchronous serial line.
        That is, there is no special character to introduce a sent frame.

        In the LNI data field, the sender applies the following rules:
        A data FRMEND octet is sent as FRMESC, M_FRMEND sequence.
        A data FRMESC octet is sent as FRMESC, M_FRMESC sequence.
        All other octets are sent without any translation.
        The receiving IP decodes by stripping and translating the extra octets.

        The LNI trailer contains only the FRMEND octet.
        That is, a frame is sent ending with the FRMEND character.

        Example:
        Want to send ('a', FRMESC, 'b', FRMEND, 'c').
        Sent as ('a', FRMESC, M_FRMESC, 'b', FRMESC, M_FRMEND, 'c', FRMEND).
        Note the last sent octet is not part of the LNI data field.

        Data Octet To Send Data Sequence Actually Sent
        Hex Octal Decimal Hex Octal Decimal
        0xdb 0333 219 (0xdb, 0xdd) (0333, 0335) (219, 221)
        0xc0 0300 192 (0xdb, 0xdc) (0333, 0334) (219, 220)

        Justification of the Rules:

        1. Sending the FRMEND data octet as a FRMESC, M_FRMEND sequence:
           We must be able to send the FRMEND as a data character,
           so the FRMEND has to be escaped, otherwise the receiver would
           misinterpret it as a premature end of packet.

        2. Sending the FRMESC data octet as a FRMESC, M_FRMESC sequence:
           Because the FRMESC is used as an escape, there has to be a way
           of treating a FRMESC as data. For example, if this rule weren't
           defined, then there would be an ambiguous packet. Suppose the
           sender wanted to send the (data_char, FRMESC, M_FRMEND, data_char)
           sequence. According to rule 1 only, there would be no translation
           of octets. Therefore the receiver would receive it as
           (data_char, FRMEND_data_char, data_char),
           which is not what is intended.

--
FullName:	Dennis Bednar
UUCP:		{uunet|sundc}!rlgvax!dennis
USMail:		CCI; 11490 Commerce Park Dr.; Reston VA	22091
Telephone:	+1 703 648 3300



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