                Using the Wisconsin Network - Part 26
                      by Andy Nemec, KB9ALN
 
     In recent installments of this series, we have been
looking toward the future, and investigating what the networks
of the future might look like. We broke the whole process of
leaving a message to a friend down to a step-by-step procedure,
and talked about how each part of the network and you interact.

     One thing we discovered was that packet radio messaging
has one comparison - the internet. We also discovered that the
protocol set used by the internet, TCP/IP is in wide use by a
number of amateur stations. While the TCP/IP amateur
implementation does not exactly duplicate the internet, it is
very close, with some accomodation of our unique radio
environment. The main attraction of the internet is the
simplicity, and the capabilities presented by an open,
transparent network. We also talked of the Network Interface
Host Computer as being a gateway for users to the network.

     Now some of you might be thinking "Geez, now he wants me
to learn some other program and run TCP/IP". Well, not
exactly. However, the network of the future may very well
include many elements of the internet, adapted for Amateur
Radio use. Your station may become a vital part of a TCP/IP
network, if you choose, or you could remain with your current
station and still utilize the services of the Network
Interface Host Computer. This is similar to what we now use,
the node stack. Instead of a conventional node stack, the host
computer would perform routing and the conversion of the
TCP/IP protocols to/from your current AX.25 protocol. Even
though you use AX.25, you would still be able to take
advantage of some advanced features of this type of
arrangement. In the final analysis, you could have a greatly
enhanced packet station with little changes in your actual
hardware or software, if you so desire. The main difference
would be in learning new terminology and new functionality.

     We have covered most of the differences between what we
now use and what we could use. And we are not quite ready to
make the big jump into radio "cyberspace". But we are close. I
mentioned some of the things that need to be added or improved
to make these advances a reality. Here is a rundown of what is
needed.

     First we need to improve the AX.25 protocol if we are
going to continue to use it. There are "spaces" in the AX.25
protocol that allow for expansion without scrapping the entire
system. One such extension needs to be the addition of forward
error correction. Remember that our current protocol will not
correct errors, only detect them and allow for a corrupted
packet to be resent. Some packet operators have used AMTOR in
the past, and recall that it uses one of two modes. One is
"FEC" (Forward Error Correction) and the other is "ARQ"
(Automatic Repeat Request). Right now, packet "gurus" are
working on this very problem, improving the protocol so that
AX.25 can be made more reliable. AX.25 is really an adaptation
of the X.25 protocol originated by the telephone industry, and
is not well suited for the kinds of things we are trying to
do. At the same time, we do need to have the capability to use
the existing protocol so that all the current TNC's will still
be useable. This is what we know as "Backward Compatability".

     The next need is the ability to maintain reliable routing
tables amongst network hosts using TCP/IP. There is one
promising protocol called "RSPF" (Radio Shortest Path First).
It needs to be refined and perfected before it can see wide
implemetation. Once done, it has the prospect of becoming far
more effective than the current Net/Rom system. RSPF actually
measures the time it takes to get to a given destination,
rather than assuming that a route broadcast is good.

     One other thing we touched on was the need for programs
that are "User Friendly" and interact with the network in a
transparent manner. Microsoft's Windows seems to be a very
popular user interface to a computer, and it also has some
TCP/IP capability available to it. This is, potentially, a
good situation for the software writer - adapt what is there
without starting from "square one". This is a good way to
incorporate new AX.25 protocol extensions too, with the
ability closely control the TNC. Most TNC's have the
capability to operate in the "KISS" mode. This allows the
computer connected to it to perform most of the processing of
packets, making it easier to utilize protocol extensions.
Of course we would not want to leave DOS users in the dust,
work would have to be done there as well. It should be
possible to use a good many of these advanced function on a
relatively simple computer. I (and others) have run TCP/IP
programs on 8 MHz 8088 computers with V-20 processors
installed. All of this was done with MS-DOS 3.3 as an
operating system. To sum it all up, we can run advanced
systems without spending a huge amount of money for hardware
upgrades. 

     Working hand-in-hand with the software approach is the
ability to assign temporary IP addresses. You recall from our
last part of the series that there are a limited number of IP
addresses availble. Anyone who has used a PPP Internet service
has used a form of this. PPP is the internet "Point-to-Point
Protocol". When you use Netscape, you are very likely using
this protocol and may not even know it! Therefore, if one were
to decide to take advantage of the more exotic aspects of a
new network, the Network Interface Host Computer should be
able to accomodate this. Currently, this is being talked about
as a soloution to Mobile/Portable TCP/IP packet radio
operation. And it would allow for easier setup of the end-user
program.

     We also need to maintain a good, high-speed radio
network.  Maintainence not only involves constructing a
network and making sure all the radios and devices function.
It also keeping the databases and host configurations up to
date. WAPR helps to build and maintain the Wisconsin network,
but it always is a struggle in a volounteer network such as we
have. Skilled people who understand networking are in demand
for both the radio and "software" types of work.

    The last thing we need to move to the "next step" is the
willingness to try new things. Obviously, we can't experiment
with a whole statewide network all at once, but we can
experiment locally and regionally. And we can spend more time
reading about and learning new ways of connecting our
computers to share information. At the same time, we can't
make what is in place obsolete. Many people have too much
invested in their current hardware and do not wish to change
from their current operating setup. It suits their needs, and
they are comfortable with it. So we need to improve the system
without "throwing the baby out with the bathwater".

     And that is the next direction we will take in this
series. Next time, we will look at what you can do to make
your packet life a little easier - automated - with little or
no change in hardware or software, just configuration.

Until next time, 73 from Andy.
