              Using the Wisconsin Network - Part 25
                    by Andy Nemec, KB9ALN
 
     In the last part of this series, we took a look at the
future of Amateur Packet Radio, and what we can do with it.
We took note of the evoloution of the packet network, and what
other changes we might want to see in it's continuing
development. We drew some paralells with the Internet, and how
we would draw on some of the networking advances that have
been made there, perhaps applying them to Amateur Radio.

     When we left the last part of our series, we broke the
network system down to a few basic functions like these:

1) A originator of data.
2) A Network Interface Host Computer (comparable to a network
   node we now use, but more functional and automatic).
3) An transparent Auto-Routing network requiring no user
   knowlege or intervention.
4) Another Network Interface Host Computer at the destination.
5) A receiver of data.

     Of course, the originator of data would be your, or any
other Amateur Packet Radio station. We mentioned that this
station could be combined with a Network Interface Host
Computer, more on that later.

     The Network Interface Host Computer can be compared to a
current node in some ways, but capable of being more "network
friendly" than our current nodes. This, as well as the network
itself, deserves the most study and contemplation.

     Just what would this computer do? Aside from storing and
auto-delivering your personal mail, it would route packets
properly, maintain a table of reachable destinations, and know
the best way to reach a destination. It could act as a gateway
to the Internet, it would allow use of different protocols to
accomplish different tasks. In effect, it could replace both
the BBS and the nodestack you are currently using, and allow
you to access the "World-Wide Web" with a text browser (if
data rates can be increased sufficiently).

     The network itself would consist of interconnected host
computers. They would exchange data concerning routing, as
well as acting as relay stations and routers to make certain
any data it handles is effectively sent to it's destination.

     While some of this sounds familiar, the methods that
these computers use to communicate would be different and far
more varied than they are now. Currently, only a portion of
the network will allow anything other than AX.25 and the
Net/Rom (node) protocols to be passed. This is the primary
difference between what we are using now and what we could use
in the future.

     In the past 3 years or so, we in Green Bay have been
doing considerable experimentaion with TCP/IP protocols - the
protocols used on the internet. Currently, we have 10 TCP/IP
stations in full-time operation, with one or two ocasionally
operating. In addition, we have a node stack that is equipped
with the X-1J4 node firmware, which allows both conventional
and TCP/IP protocols to be passed through it. While the X-1J
node does not have all of the features of the Network Host
Interface Computer described earlier, it is a mid-way point
that allows some of the advanced features we may be looking
for.

     Currently, the only real network host computers we have
are the TCP/IP stations themselves. These stations access the
network through the nodes, and work with the network. Here is
a sampling of what we have been able to do with these
stations:

1) Mail a freind without ever having to manually connect up to
   a node or a mailbox. This is done with the use of "SMTP",
   the "Simple Mail Transfer Protocol". While SMTP can
   directly deliver mail to a recipient, it's operation can be
   modified to store it at a different computer - a different
   station. 

2) If mail is left at another station, it can be automatically
   collected from that station using the "Post Office
   Protocol" (POP). Stations are configured to automatically
   "POP" the nominated "POP Mail Server" and collect mail.
   These operators don't have to remember to check into their
   local BBS - their station automatically remembers for them. 

3) Transfer text and binary files to other TCP/IP stations
   with ease. This is the "File Transfer Protocol" (FTP) at
   work. There is no need to fool with YAPP to transfer binary
   files, binaries are simply identified as such and the system
   automatically accomodates this.

4) Test a radio path by requesting an Echo. This is called
   "Pinging" a station. The Amateur Radio implemetation will
   tell you how long it takes to get an echo return, letting
   you judge how busy the network is.

5) Find out who somebody is without taking a lot of time to
   do so. This is the "Finger", kind of like tapping someone
   on the shoulder and asking "Who are you?" A short custom
   information file is returned with the answer.

     There are even more possibilities that we can talk about,
and more yet to explore. We have talked about this before in
an earlier installment of this series, but needed to repeat
this here to show the versatility of the TCP/IP protocol set.

     So now we come to the next step in the evoloution of the
network as it pertains to Amateur Packet Radio. The Network
Interface Host Computer would perform a lot of the functions
that current TCP/IP stations would perform, freeing their
resources for other things. POP Mail and the SMTP system -
automatic mail - could free things up additionally. And now
with the intense interest in the World-Wide Web, we could also
utilize that for Amateur Radio.

     Now let's talk about the other things we will have to
consider for the Amateur Radio to effectively use this
protocol set. First we need more user-friendly for the
ocassional user of this powerful system. Programs could be
stand-alone DOS versions, or based on the Windows operating
platform.

     Secondly, we need to resolve one issue that is important
to making this sytem widespread. Currently, all TCP/IP staions
are numbered, kind of like a serial number. For example, my IP
address 44.92.20.9. All Amateur Radio network stations begin
with the 44 series of numbers. Obviously, there are a limited
number of TCP/IP addresses available, and assignment of the
number varies according to location. Therefore, widespread use
and mobility becomes another complication.

     Then there is overcoming the wide-area reliable pathing
and routing of data. Right now we rely on the Net/Rom system
to do this. Although we have maybe gotten used to some of it's
shortcomings, it is not exactly reliable or automatic. TCP/IP
routing principles are borne of a wired network that is not
subject to propagation variables. So simply adapting all of
the routing techniques the Internet uses are not effective.
There have been some attempts at doing this, and progress is
being made.

     Next time we will further explore how a Network Interface
Host Computer system can overcome some of these problems, and
what to look for in the future.

  ***End of Part 25***
