n2dsy@hou2d.UUCP (G.BEATTIE) (03/29/88)
Summary: Alternatives to ASLIP, SLIP, KISS, et al...
let add in some reliability and universality to solving the problem.
References: <625@sun.soe.clarkson.edu>
I remember seeing some articles here on the net regarding the
use of these somewhat homegrown solutions to the problem of
packet data transmission (your choice of protocol suite) over
an asynchronous link. As part of the work that our non-profit
Amateur Radio group (the Radio Amateur Telecommunications Society)
is doing on OSI protocols we have developed a package for
transmitting generic HDLC frames over an asynchronous interface.
This package is based on the Asynchronous Framing Technique
that was published by Toby Nixon from D. C. Hayes. This
proposal has been well received in various ISO workgroups and
basically offers a couple of reasonable variations.
The first is basic framing, transparency, and error checking.
This mode uses two characters for special purposes. The
framing character (7EH) and the escape character (7DH) are
all that require special handling. In the normal data flow
you prefix a 5EH (corresponding to a 7EH) or a 5DH
(corresponding to a 7DH) with a 7DH. The appearance of a 7EH
uniquely signals a frame start or end. This mode also
contains a feature not found in SLIP (and I believe ASLIP):
ERROR CHECKING. There is a check calculation (I forget what
type) on every frame.
The second mode adds the X-ON and X-OFF characters to the list
of characters transmitted transparently.
The third adds in most control characters.
There are several other options like 7-bit character
transparency and packet forwarding characters which can be
added AFTER the flag to force the packet to be forwarded.
In any case, our software was written by John Howell, N2FVN
and includes source code, source for some MS-DOS drivers and
test programmes, binaries for everything for MS-DOS and a lot
of GOOD documentation.
I will post this code to the net in a few days. It will be
posted in the same sequence as the RATS Open Systems
Environment (ROSE, formerly COSI) software to the
comp.sources.misc and comp.sources.ibmpc newsgroups.
I will also post an announcement here for those who need to
be signalled to the availability of the software.
Thanks,
J. Gordon Beattie, Jr.
E-mail: ihnp4!hou2d!n2dsy (Unix) n2dsy@kd6th.a3100201.ampr
Telephone: 201-615-4168 (Office) 201-615-4669 (Office FAX)
Telephone: 201-387-8896 (Home)karn@thumper.bellcore.com (Phil R. Karn) (03/31/88)
The framing technique you describe is EXACTLY the same as SLIP, with one important difference -- the specific values of the "escape" and "frame end" characters are different. Why? Is gratuitous incompatibility with de-facto standards a prerequisite for ISO approval? I distinguish between the framing technique used by SLIP and the format of the information carried in a frame. There's nothing about SLIP framing that says you can't add a link-level CRC or checksum if you wish. It just hasn't been necessary, as there are already checksums at the IP and TCP layers. The error rate of a typical dialup link (if it works at all) is low enough that the extra software processing required to recompute a checksum over an entire packet at each hop is hard to justify. I keep a nailed-up 9600 bps V.32 modem link between work and home. In the 6 days since it was last rebooted, my machine at home has received 13,186 packets over the serial link. Of these, however, only 6 had IP header checksum errors and 8 contained TCP header checksum errors. I have also used SLIP heavily elsewhere, but I have NEVER seen a file corrupted by the failure of the TCP checksum to catch an error. The propensity of the ISORMites to reinvent the wheel (with seemingly deliberately incompatible lug-nut threads) never ceases to amaze me. Considering the popularity of SLIP, your time would be much better spent making incremental, desirable improvements (e.g., logins and passwords for switched environments) instead of devising totally new and gratuitously different protocols to do what is already being done. Phil
n2dsy@hou2d.UUCP (G.BEATTIE) (04/01/88)
POINT 1
It has been suggested that the differences between SLIP
and AFT are limited to the "gratuitous" alteration of the
transparency and framing characters.
This is hardly the case...the additional features of
AFT are three levels of charater transparency, seven-bit
transparency and prefix and suffix characters outside the
frame to manipulate any intervening devices such as modems,
PADs, etc.
POINT 2
It has been suggested that these extra features are not
prohibited by SLIP.
We agree, they are not. Unfortunately, these additional
features have not been uniformly outlined in SLIP. This
may cause the evolution of several systems using SLIP which
will each have different way of handing the variations of
transparency found in asynchronous environments. AFT DOES
standardize these conditions and I suggest that maybe SLIP
should be altered to handle them too.
POINT 3
It has been suggested that this is a divisive issue wrought
by the ISO folks to further separate the DoD Internet
and OSI commmunities.
On this point I wholehartedly disagree. In fact, the problem
is identical for both groups and should help unite them.
The OSI model is not an issue here, the aysnchronous interface
and transparency through that interface is.
POINT 4
It has been suggested that the number of errors encountered
on an Asynchronous Link is minimal, therefore some error
checking is not required on the link and that error recovery
can be accomplished on an end-to-end basis.
If I was experiencing a low residual error rate, then I would
agree. The fact is I am not. Every dial-up link I have
outside of my local area, but within my LATA is noisy.
If your requirements are less, so be it, but I would like the
have the local loop tend to it's own housekeeping and not
send errored frames on through the network and force end-to-end
recovery.
POINT 5
Anyone want to work on the convergence of these protocols into
a common solution ? Please let me know and we can get
started.
Thanks,
J. Gordon Beattie, Jr.
E-mail: ihnp4!hou2d!n2dsy (Unix) n2dsy@kd6th.a3100201.ampr
Telephone: 201-615-4168 (Office) 201-615-4669 (Office FAX)
Telephone: 201-387-8896 (Home)pritch@tut.cis.ohio-state.edu (Norm Pritchett) (04/01/88)
In article <1016@thumper.bellcore.com> karn@thumper.bellcore.com (Phil R. Karn) writes: >The framing technique you describe is EXACTLY the same as SLIP, with one >important difference -- the specific values of the "escape" and "frame >end" characters are different. Why? Is gratuitous incompatibility with >de-facto standards a prerequisite for ISO approval? For some time I've observed that phenomena and wondered the same thing. Then I attended A DECUS symposium session where DEC's representative to ANSI and ISO touched upon the subject and confirmed it is in fact true. He said the purpose of these committees is to produce a solution that makes technical sense AND places all parties involved at equal DISadvantage, this concept making more sense in a commercial environment. As a possible scenario, suppose a major vendor comes up with a neat solution to something. They development it and afterwords everyone (or if the vendor is big enough, they themselves) think it is great and submit it to a standards committee. Now, the standards committee thinks its great but some of the representatives are concerned because if the committee just puts the big rubber stamp on it then the submitting vendor is way ahead of the game because he already has the product making use of the standard developed or maybe even on the market. That vendor is now has a greater advantage over everyone else and some might consider it unfair. Making little "cosmetic" changes to the standard works towards evening out the work involved for everybody to implement the standard. In place of vendors, the standards organizations of a nation might be substituted in the case where a standard from one of them is being submitted to an internation standards organization. -- Norm Pritchett, The Ohio State University College of Engineering ARPA: pritchett@eng.ohio-state.edu BITNET: TS1703 at OHSTVMA UUCP: cbosgd!tut.cis.ohio-state.edu!pritch
egisin@watmath.waterloo.edu (Eric Gisin) (04/01/88)
In article <1016@thumper.bellcore.com>, karn@thumper.bellcore.com (Phil R. Karn) writes: [] > the IP and TCP layers. The error rate of a typical dialup link (if it > works at all) is low enough that the extra software processing required > to recompute a checksum over an entire packet at each hop is hard to > justify. I keep a nailed-up 9600 bps V.32 modem link between work and > home. In the 6 days since it was last rebooted, my machine at home has > received 13,186 packets over the serial link. Of these, however, only 6 > had IP header checksum errors and 8 contained TCP header checksum The overhead of a asyncronous link level checksum or CRC is very small. On an 8MHz 68000, Fletcher's checksum takes about 3 usec per byte, and CRC-16 takes about 8 usec per byte. This amounts to less than 1% overhead at 9600 baud, which is less than overhead of the asyncronous device driver (much less in the case of dumb asyncronous devices). Both of these are better than the 16 bit ones-complement checksum TCP/IP uses. Your example error rate is 1/1000 (high relative to LAN technologies), and I wouldn't trust only TCP/IP checksum to detect errors.
karn@thumper.bellcore.com (Phil R. Karn) (04/01/88)
> ... it is in fact true. He said the purpose of these committees is to > produce a solution that makes technical sense AND places all parties > involved at equal DISadvantage, this concept making more sense in a > commercial environment.... Thank you. I couldn't have asked for a more damning indictment of the international standards process. Someday, perhaps there'll be a protocol standards organization controlled completely by users. Realizing the importance of the process, they will each invest sufficient time and money so that they can be thoroughly versed with the technical issues. However, anyone associated with a commercial vendor of products controlled by the standards in question would be automatically disqualified from membership. I can dream, can't I? Phil
rpw3@amdcad.AMD.COM (Rob Warnock) (04/01/88)
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 94403bukys@cs.rochester.edu (Liudvikas Bukys) (04/01/88)
One should either leave SLIP alone (it works as it is), or re-do it altogether, addressing some of the most severe problems while you're at it. For instance, someone at UDEL (Dave Farber & et al) noted that header bytes are mostly predictable, and devised a faster (less wasteful) serial-line protocol for slower lines. If a SLIP working group emerges, *that* is the direction it should take off in. If you're going to have a new protocol, it might as well be better, not just different!
budden@tetra.NOSC.MIL (Rex A. Buddenberg) (04/02/88)
In article <9312@tut.cis.ohio-state.edu> pritch@tut.cis.ohio-state.edu (Norm Pritchett) writes: [...] >representative to ANSI and ISO touched upon the subject and confirmed >it is in fact true. He said the purpose of these committees is to >produce a solution that makes technical sense AND places all parties >involved at equal DISadvantage, this concept making more sense in a ^^^ Is this why ISO uses the acronym for Draft International Standard? :-) b