Xref: utzoo comp.protocols.tcp-ip:2985 comp.protocols.iso:69
Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!amdcad!rpw3
From: rpw3@amdcad.AMD.COM (Rob Warnock)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.iso
Subject: Re: SLIP working group?
Message-ID: <20989@amdcad.AMD.COM>
Date: 1 Apr 88 09:05:09 GMT
References: <1966@hou2d.UUCP> <1016@thumper.bellcore.com> <9312@tut.cis.ohio-state.edu> <1017@thumper.bellcore.com>
Reply-To: rpw3@amdcad.UUCP (Rob Warnock)
Organization: [Consultant] San Mateo, CA
Lines: 52

Uh... there is a good reason why you might not be ABLE to turn UDP checksumming
on, and thus would want some sort of (simple) CRC on your SLIP line. There was
a bug in some (all?) 4.2 BSD systems which calculated the UDP checksum wrong
(but consistently, for talking to other 4.2's), and 4.3 fixed it. So 4.3 can
now talk to non-BSD systems which checksum the right way. However, if you still
happen to have some "old" 4.2 systems on your net, and if they happen to be
binary-only systems (i.e., the kernel and/or the net code is supplied by a
3rd-party vendor who may or may not still be in business), you may have to
turn off checksumming to be able to talk UDP to them. (A client of mine has
that problem.) Since UDP checksum "on/off" is a per-host function and not per
"connection" (at least in 4.3), it's hard (without delving into the net code)
to get UDP cheksums on SLIP lines and not on the Ethernet. So a simple CRC
on the SLIP lines might be in order after all...

By the way, computing the standard Ethernet CRC-32 only takes a couple of
XOR's and a table lookup per byte (and the table is only 256 32-bit words).
The C code for the inner loop is:

	while (len-- > 0)
		sum = (sum >> 8) ^ CRC32_table[ (sum & 0xFF) ^ *cp++ ];

The overhead is thus tolerable on a serial line, even on micros, and there
is no reason not to do it (except compatibility with earlier SLIP's). My own
preference would be to extend the SLIP frame to include a full Ethernet header,
use the standard Ethernet numbers, type field, and CRC-32. (Let's call it SLEN,
for Serial Line EtherNet, to distinguish it from SLIP.)

The advantage of a SLEN is that you get ARP, RARP, XNS, DECnet (*ugh*),
and whatever else, besides IP. And you don't have to worry about lack
of UDP checksums.

(Of course, you now have to apply some clever flow control to Ethernet
broadcast packets...  ;-}   ;-}  )

Note that Xerox already defined a "SLEN" for SDLC links. See "Level 0
Point-to-Point Protocol Spec T33-2.0", XSIPS 018201, January 1982 [~6 pages].
It includes some hooks for managing half-duplex lines (might be helpful for
some modems?) in a low-level "link command", which also provided for controlled
termination of dialup connections. Note that their protocol left off the
Ethernet destination number, but kept the source (for authentication?);
the type field was cut to 4 bits (*ugh*), and the CRC was a modified
CRC-16. Still, it's almost usable as it stands, if we could grab a couple
of types for ARP & IP (or go back to 16 bits?), and change the SDLC framing
to SLIP-like async (and maybe go back to CRC-32?).


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun,attmail}!redwood!rpw3
ATTmail:  !rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403