[The following paper has been submitted to the 7th ARRL Computer
Networking Conference. You may read it and pass it on to others
to read, but please do not reproduce it in any other publication.
Copyright 1988 by Daniel M. Frank.]
[This is a DOS text version of a document originally produced
with a word processing program. In the translation process,
some text formatting may have been disturbed, and the bold
facing has definitely been lost. So, it may not scan quite
like the original. Sorry.]
TRANSMISSION OF IP DATAGRAMS OVER NET/ROM NETWORKS
Daniel M. Frank, W9NK
1802 Keyes Avenue
Madison, WI 53711-2006
ABSTRACT
One of the main design goals of the Internet Protocol was that IP
datagrams could be carried over existing local- and wide-area
networks. This characteristic of IP makes it possible to build so
called "internetworks" out of existing network facilities. We
built support for an existing Amateur wide area network, NET/ROM,
into the KA9Q TCP/IP package, allowing the use of NET/ROM to carry
IP datagrams, and adding features which make the KA9Q software
useful as a full duplex NET/ROM packet switch. We have also shown
that NET/ROM may be used as a datagram network only, independent
of its transport and application layer facilities.
INTRODUCTION
In the late Seventies and early Eighties, the world of computer
communications consisted of many isolated local- and wide-area
networks. Enough communications capacity existed to link the
entire country, and much of the world, into a single large network,
but the existing facilities were physically and logically
dissimilar. They could not simply be "plugged together" to make
this large "internetwork" (or "Internet").
The designers of the Internet Protocol (the "IP" in "TCP/IP") were
committed to overcoming the obstacles that prevented an Internet
>from developing. They came up with two key ideas:
o Gateways can be established between networks. A gateway
is a computer which possesses the physical resources and
software to connect with and speak to more than one kind
of network.
o A single protocol can be developed whose messages
("datagrams") can pass through any network, hidden inside
that network's "native" messages. When a message with
a datagram inside it encounters a gateway, the gateway
"unwraps" the datagram, rewraps it in the native message
of a second network, and sends it on its way. If a
datagram is too large to fit inside the native message
type of a network, the gateway breaks it into pieces
("fragments"), each of which is then wrapped in a native
message and sent on.
By using IP and gateways, the designers of the Internet have
created a global "network of networks", which today encompasses
hundreds of thousands of computer systems, connected to every
conceivable kind of network.
Amateur packet radio networking, like computer networking, consists
of many different network technologies and protocols. Local AX.25
communications, digipeating, TexNet, ROSE, and NET/ROM, to name
only a few, coexist or compete for dominance as the network
technology of choice. This competition is healthy, and is in the
spirit of amateur radio experimentation. Any attempt to establish
one network over another as the single "standard" is both pointless
and doomed to failure. No single standard can ever be imposed on
radio amateurs any more than it could have been imposed on computer
networks, given the investments already made in equipment,
software, and education.
As the dissimilar amateur networks grow in size, they meet up with
each other. Sometimes they coexist on the same channels. But
without gateways and some kind of Internet Protocol, each network
is an island of communication, unable to send or receive data
beyond its own shores.
The work described in this paper is a first step towards true
Amateur Radio internetworking. Using the KA9Q TCP/IP package as
a basis, we have built a software system which functions as a
gateway between local TCP/IP networks and the NET/ROM network. It
allows IP datagrams to be forwarded automatically and transparently
across existing NET/ROM facilities. In addition, as a full
implementation of NET/ROM layer 3, it is capable of functioning as
a NET/ROM relay node (as opposed to an AX.25 endpoint), and as a
full duplex NET/ROM packet switch.
IP OPERATIONS OVER STANDARD AX.25 CONNECTIONS
In order to properly understand how we have interfaced to the
NET/ROM network, we should first examine how "ordinary" TCP/IP
operations take place over AX.25. This description follows the ISO
OSI Reference Model (RM), a seven-layer classification of network
facilities.
>From the bottom up, the layers used in packet TCP/IP operation are:
(1) A physical layer, made up of the radios, antennas, and
modems used to generate and carry the tones used to
convey digital data from one place to another.
(2) A data link layer, made up of HDLC and AX.25, used to
format and address the data, detect errors and discard
bad packets. The link layer only knows about and
communicates with stations with which we are directly
connected. In the case of packet radio, this means
stations with which we have reliable, direct
communications. (Digipeating doesn't count, for purposes
of this discussion.)
(3) A network layer, responsible for routing packets to their
destinations through one or more link-to-link hops. The
main distinction between the data link and network layers
is that the network layer provides facilities for
communication between stations not directly connected.
The network layer has to have some concept of routing,
that is, the path to be taken by a packet to reach its
destination. We use IP as our network protocol.
(4) A transport layer, responsible for reliable end-to-end
communications. Our network layer does not guarantee
that a packet will actually reach its destination. While
AX.25 provides link layer acknowledgement and
retransmission, it does not guard against nodes which go
down, software errors, or a destination station which is
not on the air. The transport layer provides for an
acknowledgment to be sent from the packet's ultimate
destination, and for retries in case that acknowledgment
doesn't arrive within a reasonable amount of time.
The other function of a transport layer is multiplexing.
The network layer provides only host-to-host addressing.
However, a computer can have many users, and provide many
different services. The transport layer takes incoming
packets from the network and directs them to the proper
programs based on information contained in the transport
header portion of the packets.
Our transport protocol is TCP, the Transmission Control
Protocol.
(5) The session layer is mainly involved with providing
services to individual programs within the computer. It
is not of importance for the current discussion.
(6) The presentation layer is mainly concerned with the
uniform formatting of data, or its conversion between
different character sets. Some of the TCP/IP user
programs have a very simple presentation "layer" which
maps plain text messages in the native character set of
the user's computer, to and from ASCII with a standard
line-ending convention.
(7) The application layer is made up of the various programs
and services that use networking facilities. Users of
TCP/IP mainly make use of telnet, for keyboard to
keyboard chat and remote login, smtp for automated
transfer of mail, and ftp, for easy exchange of files.
LINK LAYER MULTIPLEXING
As can be seen from our description, local TCP/IP operation uses
regular AX.25 communications for its link layer. An AX.25 packet
containing an IP datagram contains a special code in the protocol
ID (PID) field of its header. This allows the link layer software
to forward the contents of the packet to the proper part of the
KA9Q package, in this case the IP routing code.
If the AX.25 packet contained a PID of "no level 3", the link layer
would forward it to a different part of the package, in this case
the AX.25 session code, which allows users of the package to hold
"regular" AX.25 conversations, bypassing all layers between the
link and application layers. (This brings up an important point
about the reference model we've presented: an implementation may
not contain certain layers from the RM if the services they would
have provided are unused or unneeded.)
This switching of packets at the link layer based on their PIDs is
known as link layer multiplexing. Multiplexing at the link layer
is extremely useful, because it allows different network layer
protocols to share the same data link services, and often the same
link connections. Link layer multiplexing is what allows the KA9Q
software with NET/ROM support to act as a digipeater, an IP relay,
and a NET/ROM relay node, all on the same channel, through the same
TNC.
AN OVERVIEW OF NET/ROM
Now that we understand how IP datagrams are carried over packet
radio links, we should examine how NET/ROM operates. Again, we
will use the ISO OSI Reference Model as our framework:
(1) The physical layer is the same, i.e. radios, antennas,
and modems.
(2) The data link layer is again AX.25, but the Protocol ID
field of NET/ROM packets is set to a special NET/ROM ID.
(3) The network layer of NET/ROM handles the automatic
routing of packets to their destination. A NET/ROM
network packet header contains the source and destination
callsigns of the NET/ROM endpoints. There is no
information about the route the packet will travel to its
destination. Instead, every node maintains a routing
table based on routing adjacencies: it receives
broadcasts from other nodes which say, essentially, "I
am willing to take traffic for such-and-such a node."
When a NET/ROM node receives a network packet, it
examines its routing table to see if anyone is willing
to pass it on toward its destination. If so, it hands
off the packet to the next station. If not, it simply
throws the packet away without comment.
The type of network communications service (as opposed
to the routing techniques) used in NET/ROM (and IP) is
usually called an unreliable, connectionless datagram
layer, and the network layer packets are generally called
datagrams. The service is unreliable, because it does
not guarantee or confirm ultimate delivery. It is
connectionless, because no circuit is established over
which datagrams will travel. (This contrasts with some
public data network protocols, where before data may be
sent to a remote system, a fixed path to that system must
be set up through the network, with resources
preallocated at every intervening node. Each approach
has its advantages and adherents.)
(4) The transport layer of NET/ROM uses what is called a
sequenced packet protocol. Unlike TCP, which delivers
an unsegmented stream of bytes to the receiver, and is
free to pack as many or as few bytes into each message
as it likes, the NET/ROM transport delivers a sequence
of packets. The amount of data in these packets is
determined by the amount of data in the AX.25 packets the
NET/ROM user presents for transmission. NET/ROM is not
free to combine packets together for greater efficiency,
although it can fragment and reassemble packets which are
too large to fit in one of its transport messages.
The NET/ROM transport protocol provides end-to-end
delivery and acknowledgement, as well as demultiplexing
of arriving messages by circuit number. A NET/ROM node
can be handling traffic for more than one circuit, or
connection, at a time, and it directs that traffic
internally by examining the circuit number field of the
transport header.
(5) The session layer is not present in NET/ROM.
(6) The presentation layer is not present in NET/ROM.
(7) The application layer is what a user sees when he or she
connects to a NET/ROM node. It is responsible for
responding to user commands to list routes and nodes, and
establish connections. "No layer 3" AX.25 packets
arriving at a NET/ROM node are shunted directly up to the
application layer, while "NET/ROM" PID packets are
forwarded up to the NET/ROM network layer. This link
layer multiplexing should be familiar from our earlier
discussion.
A full explanation of how the NET/ROM software works is beyond the
scope of this paper. The reader is referred to the NET/ROM manual
for further details.
NETWORK AND INTERNETWORK
Our presentation of the ISO OSI RM has been somewhat simplified.
In particular, the ISO recognizes a subdivision of Layer 3 into a
Network Layer (3A) and an Internetwork Layer (3B). Strictly
speaking, the Internet Protocol (IP) is a 3B protocol, while the
NET/ROM network service is a 3A protocol. To put it somewhat
crudely, IP is an Internetwork Layer because its messages can be
routed through multiple logically and physically distinct networks.
The same cannot be said of X.25, for example, or of NET/ROM layer
3. Our NET/ROM support in the KA9Q package reflects this
distinction.
The KA9Q NET/ROM software is not a full NET/ROM implementation.
That was unnecessary for our purposes. We didn't need the NET/ROM
transport protocol, since our reliable end-to-end services are
already provided by TCP. We didn't need the application layer, for
similar reasons. What we did need was an existing network service
that could carry our IP datagram traffic to remote destinations
simply and easily. The NET/ROM network layer was sufficient for
this purpose.
We use the NET/ROM nodes as a datagram network. When we have
traffic to pass through a local NET/ROM, our software makes sure
we have an AX.25 connection to that node, then puts a NET/ROM layer
3 header on our IP datagram and sends it off to the NET/ROM via an
AX.25 packet with a protocol ID of NET/ROM. The NET/ROM link layer
sees the protocol ID and passes the packet to its network layer,
which examines its routing table and passes the packet on to the
appropriate neighboring NET/ROM. This process continues until the
packet arrives at the destination computer running the KA9Q
software, where it is unwrapped and passed back up to the IP code.
At no point is the NET/ROM user interface or transport layer
involved. We do not have to issue CONNECT commands, or make use
of NET/ROM virtual circuits in any way. The NET/ROM nodes accept
and pass our datagrams because they do not examine the contents of
network datagrams not specifically addressed to them. We are able
to take advantage of the link-layer acknowledgements and automatic
routing of the NET/ROM system without the overhead of its higher
level services.
SOFTWARE ARCHITECTURE
Let's examine how this is done in more detail. Our once-simple
protocol stack has grown a bit by now. Let's have a look at it:
(1) The physical layer is basically unchanged (although we
did added another physical layer service, described
later).
(2) At the data link layer, we still have AX.25. However,
the link layer now multiplexes three different kinds of
packets. "No level 3" packets still go up the AX.25
session code, and IP packets will go directly up to layer
3B, but now we also direct packets with a NET/ROM PID to
the NET/ROM 3A routing layer.
(3A) Incoming packets with a NET/ROM PID go to the network
layer. This is a full implementation of NET/ROM layer
3. It has its own routing table, similar to that found
in any NET/ROM node. It sends NODES broadcasts, which
update the routing tables of neighboring NET/ROM nodes,
and updates its own routing table on receipt of NODES
broadcasts from those neighbors.
The NET/ROM layer examines incoming NET/ROM datagrams to
see if our station is their destination. If the
datagrams are not for us, the routing table is examined
to see if we can forward them on to a neighboring node
for handling. If we can, they are sent back down to the
link layer to continue their journey. In other words,
a station running the KA9Q package with NET/ROM support
can act as a NET/ROM relay station. As far as
neighboring NET/ROM nodes are concerned, they are simply
passing traffic on through another NET/ROM.
If a NET/ROM datagram is for us, the network layer makes
sure that it isn't a NET/ROM transport packet. If it is,
it is dropped. If it isn't, it is sent up to layer 3B.
(3B) The internetwork layer contains the IP router and
protocol code. (Remember that IP has its own routing
table and algorithms!). It receives AX.25 traffic with
a protocol ID of IP, as well as IP datagrams arriving in
NET/ROM network datagrams.
The remaining layers are the same as before, so we won't repeat
them.
IP ROUTING VIA NET/ROM
The IP routing table is similar, although not identical, to the one
used for NET/ROM. It contains two kinds of entries, which we will
call local routes and gateway routes.
A local route consists of an IP address and an interface name. The
KA9Q software supports multiple interfaces, similar to the way that
NET/ROM supports both a TNC's modem and its serial port. One
component of a route, both in NET/ROM and the KA9Q package, is the
interface through which an outgoing datagram should pass. (The
main difference is that, while NET/ROM only supports AX.25 and two
interfaces, the KA9Q code supports many different link layers and
an almost unlimited number of interfaces.) When a local route is
found in the IP routing table, this means that the station with the
given IP address is on the local subnet, which for packet radio
purposes means that it is within radio communications range. The
datagram is forwarded to the link layer with an indication that
direct delivery should be attempted.
A gateway route consists of an IP address, an interface name, and
a gateway IP address. When we encounter a gateway route, it means
that the station in question is not on our local subnet (i.e. not
within radio range), and must be reached via a relay station, or
gateway. (You will recall the idea of gateways from our earlier
introduction of internetworking.) The IP datagram is forwarded to
the link layer with an indication that the message should be sent,
not directly to its destination, but to the gateway station, which
will make an attempt to reach the recipient, perhaps via another
gateway.
When we added the NET/ROM support, we were concerned that it be
fully transparent to the IP layer, both out of concern over proper
design, and out of a desire to avoid any unnecessary rewrite of the
existing code. One key assumption in the KA9Q IP routing software
is that of routing adjacency: the IP layer makes the assumption
that it can reach, via the interface given, some IP address
mentioned in the route entry (either the recipient or the gateway).
However, we are using NET/ROM precisely because there is no IP
station within radio range who can handle our traffic. In order
to maintain the adjacency assumption at the IP layer, we had to
simulate the presence of an adjacent IP station in the NET/ROM
code.
An IP route which uses the NET/ROM support looks just like any
other routing table entry: it consists of a destination, an
interface, and an optional gateway. The only difference is that
the interface is called "Netrom", and it's not a link layer
interface at all, although it appears that way to the IP routing
code. When the IP layer sends a datagram down to the NET/ROM
"interface" for handling, it is actually calling a small stub
routine above the NET/ROM routing code. This stub looks up the IP
address in a table which associates IP addresses, used at the IP
layer and above, with AX.25 callsigns, used by NET/ROM's network
layer. If it finds an entry for the given IP address, it creates
a NET/ROM network layer datagram header with a destination address
set to the AX.25 callsign found in the association table, prepends
this header to the IP datagram, and hands it off to the NET/ROM
routing code.
The NET/ROM routing software now handles the datagram exactly as
it would any NET/ROM traffic coming in from outside: it checks to
see if there is an entry for the destination AX.25 callsign in its
routing table. If there is, it opens a link layer (AX.25)
connection to the neighboring NET/ROM node advertising the best
quality route, and forwards the message into the NET/ROM network,
to be delivered (ultimately) to the station whose AX.25 address is
that in the destination field of the NET/ROM network header, and
whose IP address was that of the destination or gateway in the IP
routing table entry.
This approach was extremely successful. Not one line of code
needed to be changed in the IP routing code of the original KA9Q
package.
FEATURES TO SUPPORT NET/ROM PACKET SWITCHING
As implied above, the KA9Q package allows an almost unlimited
number of interfaces to be used for receiving and forwarding
packets. At the IP layer, datagrams are routed from interface to
interface using information from the IP routing table. We added
a similar functionality to the NET/ROM routing layer, allowing it
to receive and send NET/ROM traffic on any AX.25 interface it is
configured to use. This feature allows the KA9Q software with
NET/ROM support to be used as a multi-port full duplex NET/ROM
packet switch, using standard TNCs or modem boards available for
the IBM PC. This is vastly superior to the practice of wiring
together several NET/ROM TNCs with a diode bridge. There is no
possibility of collisions, since each TNC has its own serial port
or bus address, so the interfaces can all run at full duplex, full
speed through the switch. In addition, this arrangement can be
used with the high-speed interfaces and modems now becoming
available, far exceeding the capabilities of a standard TNC.
In several places in the United States, excess bandwidth on
commercial data links is being used to carry NET/ROM traffic.
These "wormhole" links work fairly well when there is only one
NET/ROM at each end, but their performance degrades quickly if more
are added. Beyond the difficulties inherent in the diode bridging
scheme shown in the NET/ROM manual, there is an additional problem
not amenable to a simple hardware solution. Most of the data links
being used are running through time-domain or statistical
multiplexing hardware, or through public data networks. While all
of these provide some kind of carrier detect indication, in almost
every case that indication comes far too late to avoid collisions.
Carrier sense simply doesn't work, since the carrier indication
isn't there when it is needed, and arrives just in time to cause
unnecessary delays afterwards. Performance of such an arrangement
is likely to degrade to below that of schemes using no carrier
sense at all.
NET/ROM nodes use a simple serial framing method to communicate
with each other over their serial ports. We have added support for
this framing method alongside the "KISS" protocol which the KA9Q
package normally uses to communicate with TNCs. It is possible to
plug a number of NET/ROM TNCs directly into the serial ports of an
IBM PC, and use the PC as a switch. Some of those NET/ROM TNCs can
be at the ends of "wormhole" links. These links can run at full
duplex with no collisions, thus getting maximum performance and
almost zero retries (assuming reliable data lines and serial
interface hardware). The NET/ROM serial interface code is
instrumented to provide statistics on traffic volume and error
rates on its serial ports.
LESSONS LEARNED
The creation of the NET/ROM code has provided some interesting
lessons on how we should and should not go about building amateur
packet networks. One of these lessons became apparent before we
even thought of writing the NET/ROM code.
We would probably not even have added the NET/ROM layer three
support to the KA9Q package had there been an easier way to
accomplish what we wanted, which was to use NET/ROM networks to
handle our IP traffic until we could build our own IP network.
Unfortunately, the NET/ROM software has a rather unfriendly link
layer multiplexor. It sends "no layer 3" packets to the
application layer, and "NET/ROM" packets to the NET/ROM network
layer, but anything else it consigns to oblivion. We could have
built fairly simple code to establish connections and send our IP
traffic over NET/ROM transport circuits, but any packet with a
protocol ID of "IP" was simply dropped by the NET/ROM software.
So, lesson number one:
If you're going to build a networking product, write the
multiplexing code to be inclusive, rather than exclusive.
In other words, if you get something with an unfamiliar
protocol ID, wrap it up and send it on, remembering to
regenerate the PID properly on the other end.
Another problem we encountered was the lack of a protocol ID field
in the NET/ROM network layer header. Both AX.25 packet headers and
IP datagram headers contain a field which indicates what sort of
higher level protocol stuff is packaged inside. This is not unlike
the cans on your grocer's shelf: without a label, you have a hard
time telling the beets from the beans. The AX.25 protocol ID field
makes link layer multiplexing possible, and the protocol ID of an
IP datagram header allows many higher level protocols to use its
internetworking services. Because the NET/ROM network header does
not contain a protocol ID field, there is no straightforward way
to put anything but a NET/ROM transport packet inside. This is
unwise. The authors of NET/ROM may well have been unaware that
anyone would ever attempt a project such as ours, but by leaving
this feature out of their network layer, they made it difficult,
if not impossible, to ever introduce other transport protocols into
their product line. So, lesson number two:
Include a protocol ID field in your link and network
layer headers, even if you can't think of a use for it
yet. Make it big enough to be useful, and offer to be
the repository of assigned PIDs, so that a standard
develops.
In experimenting with the auto-routing code in our NET/ROM network
implementation, we discovered something that is a common complaint
among NET/ROM operators. This can be summed up by the dictum,
"Just because you can hear them, doesn't mean they can hear you."
It is not unusual to have neighboring nodes that are "alligators"
(big mouth, tiny ears) or for your node to be a "rabbit" (big ears,
tiny mouth). Also, band openings on two meters happen quite often,
and usually last just long enough for you to receive a routing
broadcast from a station from whom you will never hear again - at
least until the next band opening. Either situation leaves your
routing table cluttered with impossible routes, which can lead to
repeated link-layer retries and transport layer failures. Routes
based on band openings age out fairly quickly. Ones based on deaf
neighbors come back, again and again.
After a bit of experience with this phenomenon, we added the
"nodefilter" feature to our implementation. The user may specify
a list of nodes which are the only ones from which route broadcasts
will be accepted, or alternately, may specify a "reject list" of
nodes whose broadcasts will be routinely ignored. The lesson:
If your routing method involves broadcast in an
asymmetrical or inconsistent communications environment,
provide a way to restrict the routes accepted to those
offered by reliable nodes.
The implementation described was actually the second one we did.
The first one grabbed AX.25 interfaces away from the IP part of the
KA9Q code, and could only be used for NET/ROM and regular AX.25
traffic. This appeared to be a horrible idea from the moment the
first version was completed, and prompted an immediate rewrite,
producing a program that could act as a packet switch for IP as
well as NET/ROM. The lesson here (besides "look before you leap")
is:
If you're going to build a packet switch for amateur use,
support link layer multiplexing, and try to make it
multi-purpose. This is a hobby, and the radios, tower
space, and dollars are in short supply. The more stuff
you can do with a single one of each, the happier you
will be in the long run.
EXPERIENCE
At this writing, experience with the software is necessarily
limited. It is only now being made an official part of the
official KA9Q release (thanks, Phil!), so it has not been widely
available as for as long as we would have wished. Still, it has
found its way into enough hands for us to have some preliminary
measurements and impressions.
The Madison, Wisconsin NET/ROM node (MAD) is connected to a node
(MQTA) in Marquette, in the Upper Peninsula of Michigan, via a
multiplexed commercial data line. We have conducted tests between
W9NK, in Madison, and KV9P, in Alpha, Michigan. Both stations sent
periodic routing broadcasts to announce their presence to their
local nodes. The path chosen by NET/ROM was:
W9NK <-> MAD <-> MQT <-> MQTA <-> IRN <-> KV9P
where MQTA and IRN were NET/ROM or TheNet nodes in Marquette and
Iron Mountain, Michigan, respectively. All nodes except the two
using the data line were on two meters, with a speed of 1200 baud.
Performance was surprisingly good, with TCP round trip times
settling in around 12 to 20 seconds, with a standard deviation of
about nine seconds. In spite of the number of hops, performance
was good enough to hold fairly coherent keyboard-to-keyboard
conversations.
We did note at least one case where duplicate copies of datagrams
were delivered by the NET/ROM network. Since TCP discards
duplicates, this causes no problem in normal operations, but in the
case we noticed it resulted in two replies to the same ICMP Echo
Request message (produced by the ping command).
Feedback from other users, particularly N0AN in Iowa, illuminates
a serious problem with the management of existing NET/ROM networks:
the routing tables of these networks are so inaccurate that many
experienced users don't use the network layer facilities at all!
BBS mail forwarding scripts are set up to establish connections to
the local NET/ROM node, request a transport connection to a
selected neighbor, then from that neighbor to another, and so forth
to the NET/ROM node in their destination area. They have
discovered that, without human intervention, many NET/ROM networks'
routing facilities break down and become unusable.
This problem has some impact on normal operations, in the sense
that these multiple transport sessions do not in any sense add up
to end-to-end protocol support. There is in fact no transport
facility (as we understand the term) in use in these cases, since
no acknowledgements travel from one end of the communications path
to another. There may as well be no transport layer in NET/ROM
under these circumstances; the overhead would at least be
substantially lower, with no additional loss of reliability.
Unfortunately, networks in such a pathological state are unusable
by our TCP/IP software. Since we make no use of the NET/ROM
transport layer, we must rely entirely on the accuracy of the
network layer routing tables to support the forwarding of our
packets to their destinations. If these tables are not correct,
our traffic will not get through.
The good news is that, in some areas where the NET/ROM operators
are also working with TCP/IP, this problem is forcing them to pay
attention to the quality of their routing tables. As we have noted
above, NET/ROM is somewhat short on facilities to do this, but a
few things can be and are being done with the tools available. One
side-effect of the TCP/IP NET/ROM support may be an improvement in
quality of service to all NET/ROM users!
FUTURE DEVELOPMENT
We hope, at some point, to produce a version of this support that
can be put into ROM and used in a dedicated packet switch for
hostile environments. Such a switch would allow us to begin
building IP networks, while also offering superior performance to
the NET/ROM community. It is our hope that the two user
communities can work together, sharing resources to build a better
network than either could alone.
ACKNOWLEDGEMENTS
Sincere thanks are due to Phil Karn, KA9Q, who would have been rich
(or at least, richer) by now if he hadn't been dedicated to
improving the state of the art for all radio amateurs. Also,
thanks to everyone on the tcp-group mailing list, who contributed
helpful comments during the design and development of the NET/ROM
code. Special thanks also to Howard Leadmon, WB3FFV, and John
Limpert, N3DMC, who got it to compile under Unix.
Individuals who helped test or provided feedback on experience with
the software were: Duane Brummel, NX9K; Hasan Schiers, N0AN; and
Dave Reinhart, KV9P.
Phil Karn, KA9Q, reviewed the first draft of this paper, providing
many helpful comments and suggestions.
Ritorna a Software Radioamatoriale by
IW3FQG