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 accommodation 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 Compatibility".
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
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.
On to Part 27 - General info on mail forwarding to a TNC mailbox
Back to Part 25 - TCP/IP and future Packet Radio
Back to the Using the Wisconsin Network Index - Choose a different part to view
Back to the WAPR home page - Look at something else