Date: Thu, 13 Jan 94 04:30:02 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V94 #9
To: tcp-group-digest
TCP-Group Digest Thu, 13 Jan 94 Volume 94 : Issue 9
Today's Topics:
a blast from the past
DOS-OS/2 TCP/IP
KISS and SLIP
Packet Drivers
TNC3? (2 msgs)
Usenix
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Wed, 12 Jan 1994 19:59:24 -0800
From: brian@nothing.ucsd.edu (Brian Kantor)
Subject: a blast from the past
To: tcp-group@ucsd.edu
I just found a note I wrote back in 1988:
My view of the AMPRNET
In my vision of the AMPRNET, the network consists of a moderate
number of specialized network nodes dedicated to the network itself
that provide forwarding, routing, and access to the network. Each
of these nodes is conceptually similar, and characterized by:
1. High-speed links to its neighboring nodes. Right now 56kb on
900MHz and/or 1200MHz is the method of choice; in future other
bands and rates will become preferred.
2. Duplex operation. Each node will have an exclusive transmit
frequency in its area, and will listen for its neighbors on their
respective frequencies. Thus the typical node will have more
receivers than transmitters, with a node having N neighbors having
N receivers.
NB: if it is anticipated that two neighbors to a high-density node
will each have low enough traffic to should share a frequency, that
can be done, but there is a problem with hidden-station frequency
contention to be solved. This can be done by using a low-bandwidth
channel as a busy signal - a transmission on the busy channel
indicates that the high-density node is hearing signals on the
corresponding high-speed data channel. A node with more than one
input that is to be shared would use different tones on the busy
channel to indicate which of its input channels is in use.
3. Connectivity to each neighboring node is maintained by using a
permanent virtual circuit from the node to each of its neighbors.
(For now, these will be AX.25 connected-mode streams. Later, when
we have a better legal protocol, we'll use it.) These PVCs will
use a keepalive message to periodically test connectivity and to
ensure a minimum channel presence. The keepalive will have the
benefit of ensuring proper station identification on an otherwise
idle link as well. A link which times out is marked as down,
disconnected, and connection is periodically retried.
4. Adjacency information is exchanged by nodes listing each of
their operational neighboring node connections and an indication
of the current or averaged outgoing queue length. This data is
periodically multi-cast to each of a node's operational neighbors.
The protocol to be used for exchanging this information is not yet
defined.
5. Routing is done by compiling a list of each node's link adjacency
information and associating this with a list of the subnets for
which that node is a gateway. A network-wide table of routes can
be built by flooding this information among the nodes of the network,
probably at some infrequent periodic interval or perhaps in response
to an event such as a node outage. Restrictions need to be placed
on the frequency of such updates to ensure that the networks bandwith
is not consumed by such messages.
NB: it is not necessary for a list of all reachable IP addresses
to be propagated throughout the network, but only a list of subnets
and the nodes which can gateway to them. The algorithms for
calculating this routing are not perfected and should be the subject
of considerable experimentation.
6. Multiple subnet gateways are possible, and often desireable.
When such exist, it will be desireable for each of the gateways
for a subnet to exchange host reachability information, which can
be used to determine which of a set of gateways to a subnet is
preferred for traffic to a specific host on that subnet. This
information can be obtained from static tables, connection history,
or wiretapping algorithms, and is used to issue ICMP Redirect-for-Host
messages, or to calculate second-best-route information. The
protocol for exchanging this information is as yet undefined.
7. User access to the network is made available by additional ports
on the network node. A popular node in an area with avid experimenters
might need several of these: perhaps 1200bps on 145MHz, 9600bps on
222MHz, and 56kbps on 433MHz. User stations will not normally
participate in the node-to-node links and should stay off those
channels. Both vanilla-AX.25 connected terminal mode (i.e., a
telnet server) and IP forwarding should be available to users so
that the network can be used by both basic and advanced packeteers.
NB: the PS-186 network processor was designed with 4 high-speed
ports [and capability of expansion to more] for precisely this sort
of application.
8. Services such as message drops and ftp warehouses should not be
provided by the network nodes. Instead, they should be similar to
user stations and access the node on one of its access ports. It
would be possible to use coupled processors, perhaps connected by
non-radio means such as an SCSI port, in those areas where the
network node and the service host can be installed together, but
the key is to not burden the network processor with non-network
tasks.
9. Diverse connection types should be possible. Satellite paths,
wormholes, high-speed non-radio (optical?) links, perhaps even
gateways to other types of networks [eg, the W0RLI BBSs] may be
desireable. Some of these are more advanced applications than a
simple packet switch may wish to provide [eg, a telnet-to-AX.25-stream
server to allow connection in keyboard mode from the network to a
vanilla user TNC], but other node implementors may consider them
to be an essential part of the network and thus will provide them.
Again, the protocols and facilities for many of these kinds of
services have yet to be designed.
10. Political considerations should be taken into account in the
development, construction, operation, and placement of nodes. It
might be desireable that a node be sponsored by a packet radio club
or other organization to ensure that nodes don't come and go with
the vagaries of personal whim, but conversely, they should not be
bound by some feelings of "we have to provide something the paying
users can see NOW." This is a narrow ledge to tred, but it is
clear that this network is now and will remain for some time an
EXPERIMENTAL project, not a common carrier. We should feel
unrestrained in trying new protocols, algorithms, hardware, and
concepts in our network. In other words, we should not be afraid
to break the network occasionally. After all, we're trying to
advance the state of the art here, not replace the telephone network.
As an ESSENTIAL part of this effort, people experimenting with this
network should make their experiments, results, and probably their
software available to other experimenters. It is thus incumbent
upon experimenters to PUBLISH THEIR WORK.
NB: Phil Karn's 'NET' package is an excellent example of how to do
this. It is copyrighted, available at no charge to the ham radio
community, yet he does license it and collect some money for
commercial uses. Thus the hams get to play for free, and he isn't
deprived of remuneration for his endless hours of effort. Everybody
wins.
------------------------------
Date: Tue, 11 Jan 1994 18:59:28 -0500 (EST)
From: Mike Bilow <MIKEBW@ids.net>
Subject: DOS-OS/2 TCP/IP
To: crompton@NADC.NADC.NAVY.MIL
IBM posted the details of their special offer for TCP/IP v2.0 for OS/2 2.x
at their software.watson.ibm.com machine. I think the file was
tcpip20.ann, but I don't remember it in detail and I certainly could not
point anyone to a directory.
The OS/2 Special Edition, commonly known as "OS/2 2.1 for Windows" is
widely available on retail shelves. The local Egghead and CompUSA have
had it for some time, since about mid-November. The price is $49 for the
floppy disk version and $39 for the CD-ROM version, but this is a special
that is scheduled to end on Feb. 4.
There is a FAQ file I have seen, probably on ftp-os2.cdrom.com,
os24wfaq.zip, which answers the common questions about the "OS/2 for
Windows" product. Basically, it is a full version of OS/2 that assumes
you already have Windows 3.1 installed. The price is lower, since IBM
does not have to pay the royalties associated with the WIN-OS/2 component
of regular OS/2 to Microsoft, and the amount of disk space required is
reduced by the 10 MB or so that WIN-OS/2 uses. The functionality of OS/2
for Windows when installed after Windows 3.1 should be the same as that
of regular OS/2. (The only technical difference that I know about is that
the Win32s patches can be installed after OS/2 for Windows, but not at all
with regular OS/2.)
-- Mike
------------------------------
Date: Wed, 12 Jan 94 17:16:14 GMT
From: Jan Schiefer <jas@hplb.hpl.hp.com>
Subject: KISS and SLIP
To: TCP-Group@UCSD.EDU
Phil writes:
> [..]
> As time goes on, I become even more firmly convinced that "smart"
> controllers are a dumb idea. Controllers should be simple, fast and
> easy to program. The host computer should do the rest of the work.
> [..]
> purpose host computer CPUs and memory. And for every host cycle that
> you save offloading some protocol function, you end up spending it on
> some new complex host-to-front-end protocol that you didn't need
> before.
Agreed. So if you *have* to have a frontend you want as much as
possible of the host-frontend communication protocol done in hardware.
Ethernet is an example for this, with the powerful chipsets available.
Another option might be to use IEEE488 (or HPIB, GPIB, IEC625, whatever
you prefer). No, don't say 'b...s...' to quickly, read on. It is easy
to implement, has quite a good performance, no flow control problems
because of the acknowledge lines, you can put up to 15 devices to a
single interface and you have some protocols for arbitration (like
parallel and serial poll).
To test this idea I have built a simple add-on interface for a TNC2
which consists of 5 chips (a GAL, a latch, a NEC TLC7210 IEC-bus
controller and two line drivers) and a DIP-switch for the bus address.
The interface is attached to the TNC by piggybacking the SIO and adding
two more cables. The test software works, but unfortunately I haven't
had the time to adapt some packet software to it yet, so I am still
lacking real-life performance figures.
With IEEE488 one is not restricted to host-frontend comms. You can have
controller-controller as well.
I'd be happy to hear any comments about this approach. Ah yes, and the
PC interface is just as trivial and cheap as the TNC one.
73,
Jan, g0trr//dl5ue
--
Jan Schiefer, g0trr, jas@hplb.hpl.hp.com, HP Labs Bristol, UK. +44 272 228344
Finally, I discovered a way to create lines longer then 80 columns, even on term
------------------------------
Date: Wed, 12 Jan 94 14:35:45 EST
From: waltp@bingsuns.cc.binghamton.edu (waltp)
Subject: Packet Drivers
To: TCP-Group@UCSD.edu
Does anyone know where I can get packet drivers for a
3com 3c523b (microchannel ethernet board) and / or IBM's
microchannel token ring board?
Thanks
Walt
--
--- Walter G. Piotrowski waltp@bingsuns.cc.binghamton.edu
--- Computer Science Department - Binghamton University
--- Binghamton, NY 13902-6000 (607) 777-4368
--- Ham Packet: wb1ere@wf2a.ny.usa.na Ham TCP/IP: 44.69.0.41
------------------------------
Date: Wed, 12 Jan 1994 09:48:56 -0500
From: Gary Skuse <grsk@troi.cc.rochester.edu>
Subject: TNC3?
To: tcp-group@ucsd.edu
Can anyone shed some light on the rumors we've heard about a TNC3? There
is some obvious room for improvement on the TNC2 design and I am curious
about whether anything has been done. I guess the most important question,
is whether a TNC3 currently exists or whether is is "planned"? Thanks for
any light you can provide.
73, ka1njl
------------------------------
Date: Wed, 12 Jan 1994 08:55:50 -0800
From: brian@nothing.ucsd.edu (Brian Kantor)
Subject: TNC3?
To: tcp-group@ucsd.edu
I saw a breadboard (wirewrapped?) version of the TNC-3 at a TAPR meeting
a year or two ago. At the time, it seemed to me to be an underwhelming
achievement, as it really didn't do more than update the TNC to a newer
bigger faster processor, and I think it added a second port.
In other words, it looked like a Kantronics data engine to me.
Perhaps I missed something.
By the way, I get the feeling that TAPR has lost its edge. It seems
it's more of a social club than a technical innovation group these days,
although Lyle is still coming up with new things. I suspect he'd do
that even if TAPR folded.
- Brian
------------------------------
Date: Wed, 12 Jan 1994 21:03:30 -0800
From: brian@nothing.ucsd.edu (Brian Kantor)
Subject: Usenix
To: ham-bsd@ucsd.edu, tcp-group@ucsd.edu
If any of you will be attending the Usenix conference in San Francisco
next week, we may want to get together and have lunch or drinks or something.
I'll put a note on the message board or something if there's any interest.
- Brian
------------------------------
End of TCP-Group Digest V94 #9
******************************
******************************