brian@sdccsu3.UUCP (Brian Kantor) (08/26/84)
The following paper was presented at the Los Angeles Amatuer Packet
Radio Group meeting on Saturday, Aug 25 1984.
ihnp4 \ Brian Kantor, UC San Diego
decvax \
akgua >---- sdcsvax ----- brian
dcdwest/
ucbvax/ Kantor@Nosc
"not at all a well cat..."
-------- cut here ----------
_A _P_r_o_p_o_s_e_d _N_e_t_w_o_r_k
_f_o_r _t_h_e _i_n_t_e_r_c_o_n_n_e_c_t_i_o_n _o_f
_A_m_a_t_e_u_r _D_i_g_i_t_a_l _P_a_c_k_e_t _R_a_d_i_o _S_t_a_t_i_o_n_s
_B_r_i_a_n _K_a_n_t_o_r, _W_B_6_C_Y_T
_U_n_i_v_e_r_s_i_t_y _o_f _C_a_l_i_f_o_r_n_i_a, _S_a_n _D_i_e_g_o
_I_n_t_r_o_d_u_c_t_i_o_n
The growth of digital communications in the amateur
radio service during the past few years has been nothing
short of incredible. More than anything else, the ready
availability of digital packet communications using sophis-
ticated packet controllers such as the Vancouver [VADCG],
Tucson [TAPR], and GLB devices has introduced packet commun-
ications to many hams who would not otherwise have become
involved in digital communications. Beyond these packet
controller's function as sophisticated replacements for
mechanical teleprinters, they provide a means for the estab-
lishment of message systems and bulletin boards by permit-
ting direct connection to personal computers.
While some use of packet radio has been made on the HF
bands below 30 MHz at lower data transmission rates, the
greatest activity is currently on VHF-FM (particularly 2
meters). Since dependable VHF communication is limited to
(at most) a hundred miles or so from one home station to
another, the number of stations that can be contacted by
packet radio is somewhat limited.
_R_e_p_e_a_t_e_r_s _a_n_d _D_i_g_i_p_e_a_t_e_r_s
Since the digital transmissions are converted to and
from audio signals using standard modem technology, it is
possible to send packet transmissions through ordinary voice
repeaters. There are both technical and social problems with
this practice, however, which make it unwise to do so.
Technically, many voice repeaters have audio response
characteristics that, while not really noticeable with voice
transmissions, introduce significant distortions that reduce
the reliability of digital retransmission. Additionally,
Morse code or voice identifiers, frequency or signal
_________________________
Much of the work in this paper is the direct outgrowth
of continuing discussions with Mike Brock, WB6HHV and
others in the Southern California packet radio communi-
ty.
Author's current address:
Brian Kantor, Computer Center C-010, UCSD, La Jolla, CA
92093 [sdcsvax!brian -or- kantor@nosc]
- 2 -
strength telemetry tones, and `over' beeps all may be con-
fused as packet signals by the less sophisticated packet
controllers.
Socially, the harsh sounding modem tones generated by
the packet equipment are annoying in the extreme for voice
users, leading to jamming, interference, and general unhap-
piness. Also, many packet controllers recognize only packet
modem tones, so they do not acknowledge that a frequency is
busy when it is occupied with voice transmissions, and may
transmit on top of an existing voice conversation.
Digital repeaters, known as _d_i_g_i_p_e_a_t_e_r_s, provide a
means for automatically retransmitting packet signals, but
because packet acknowledgments must be returned from the far
end of the connection over the possibly multi-hop link path,
the effective rate of transmission is greatly decreased.
Also, there is currently no collision checking when signals
are digipeated. Thus, in case of a packet collision,
current digipeaters cannot detect the collision and
retransmit the packet that was destroyed by the collision.
The originating station must therefore await the lack of
acknowledgement from the far end of the connection and
resend the packet. Repetition of sent packets from the ori-
ginating station may very well occupy large amounts of a
network's available transmission capacity.
_T_h_e _N_e_t_w_o_r_k _S_o_l_u_t_i_o_n
We feel that the solution to these problems lies in a
dedicated network for packet communications, much like the
packet switching networks that regularly move millions of
characters of data across the country and around the world
every day.
The network is simple. Each community (or geographic
area) has at least one Packet Network Controller [PNC] to
serve as a network _g_a_t_e_w_a_y which would be the access to the
packet network for that area. These stations would function
automatically, without a human operator, and would serve to
provide connections for local and network users. Each PNC
would have at least one neighbor PNC, and could make logical
connections to and through the adjoining PNCs.
_T_h_e _S_t_r_u_c_t_u_r_e _o_f _t_h_e _N_e_t_w_o_r_k
AMPRNET[1] is structured as a mesh of PNCs, each having
one or more neighbor PNCs to which it can connect via radio
links. Each of these PNCs has connections to other PNCs,
and so on, until all PNCs in the network are reachable
_________________________
[1] Thanks to Hank Magnuski, KA6M for the network
name.
- 3 -
through one or more hops. Connections between nonadjacent
PNCs are made by having adjacent PNCs relay the packets
between the two endpoints of the logical connection.
Every PNC has a routing table which describes at least
one path to every other accessable PNC. By using this table,
it is possible for any PNC to contact any other PNC, possi-
bly through a number of intervening relay hops. The routing
table is dynamically built and updated as the network topol-
ogy changes with nodes coming in and out of service.
_T_h_e _U_s_e_r _V_i_e_w _o_f _t_h_e _N_e_t_w_o_r_k
A connection is established via the network in two dis-
tinct steps. First, a user connects to the local PNC. We
have chosen the use of the ssid (station sub identification
field) value 14 (fourteen decimal) as the reserved designa-
tor for PNC stations, so a connection initiated from (for
example) a TAPR TNC might appear as
CONNECT WB6CYT-14
which would instruct your station to connect to the PNC run
by WB6CYT. A `connected' message, followed by a `network
ready' message would appear on your screen.
Next, you would instruct the PNC to attempt to connect
to the station you wanted to call. In order to do this, you
must know the identification of the PNC serving his area.
So, for example, to contact Harold Price in Los Angeles, you
might instruct the PNC to connect you to his packet station
via one of the Los Angeles PNCs:
CONNECT NK6K@WB6YMH
(the -14 is implied here)
assuming that WB6YMH was operating that PNC. The network
will take care of establishing the connection and all rout-
ing of packets necessary. When the conversation is finished,
disconnecting from either end will cause the virtual connec-
tion over the network to be closed as well. Note that con-
nections may be entirely local with only the local PNC
involved; this provides a more reliable local-area repeated
connection than current digipeater technology can.
We plan to have the PNC supply other services as well.
Among those planned for are
o+ Who's On Listing
o+ Network Status
o+ Time and Date Server
o+ Site Security Monitor
- 4 -
_N_e_t_w_o_r_k _P_r_o_t_o_c_o_l_s
While there are many proposals to establish a standard
protocol for linking of amateur packet stations, there
currently are no experimental results showing a clear advan-
tage for one choice over another.
The protocol chosen must take into account two dif-
ferent aspects of the network. First, there is the question
of transport between nodes of the network, and second, the
format of the data carried by the network. These are not
necessarily solved by the same answer.
The _t_r_a_n_s_p_o_r_t protocol describes the method chosen to
carry messages between nodes of the network. While for a
hardwire line a simple serial ASCII link would be suffi-
cient, for the more common radio links, a reliable means
should be chosen. In our research, we found that the present
implementation of the _A_X._2_5 protocol (used by TAPR, VADCG,
GLB, and others) would serve well. It has error detection
and correction, is efficient, and both software and hardware
for its use are readily available. For these reasons, we
have chosen to use the AX.25 protocol for most node-to-node
radio links on the network.
The _A_M_T_O_R communications protocol also has some dis-
tinct advantages for links that are on the HF amateur bands.
In cases where the links between network nodes are to span
large distances, the AMTOR protocol could be used and we
think it would serve well.
The format of messages carried by the network is
independent of the transport protocol used. Because it is
expected that links will fade and suffer interference, and
that nodes will fail, it is wise to use a protocol that is
robust enough to recover from many such problems. After
extensive searches of the literature and considering the
base of already installed software and systems, we have
chosen the _I_n_t_e_r_n_e_t _T_C_P/_I_P mechanism for the message proto-
col.[2]
TCP/IP is designed to operate with an unreliable tran-
sport system, and its performance improves when the underly-
ing transport system is more reliable. It incorporates
packet reassembly and reordering mechanisms that can cope
with lost packets, packets received out of order, and dupli-
cated packets. Since the network routing scheme described
below will accomodate a failed node by routing around it as
_________________________
[2] A special note here to thank Phil Karn, KA9Q for
his suggestion that TCP/IP could run on top of AX.25 -
Phil, it was a brilliant idea and solves a problem we'd
been discussing for some time.
- 5 -
long as a path exists between the endpoint network nodes of
a connection, it was a great advantage to chose the TCP/IP
protocol which would correctly utilize such a facility.
TCP/IP also has other advantages which we think places
it as the top contender for the internal message protocol.
It has been proven by over 10 years of use on the DOD
Arpanet/Milnet/Internet; implementations are available for
computer systems ranging from VAX mainframes to the IBM PC;
it is completely defined and documented; other facilities
which use the TCP/IP protocol for file transfer and remote
computer use already exist; and much of the software needed
to implement TCP/IP is available at no charge.[3]
Therefore, it is planned to implement the network such
that all inter-PNC communication is performed using Internet
Protocol [IP] datagrams to allow for maximum flexibility in
the routing and transport of data, regardless of the kind of
link used between nodes. This allows direct interconnection
to the Internet or any other IP compatable network should
such be desired.
Hank Magnuski, KA6M, has obtained a Class-A internet
network number assignment for amateur packet radio.[4] It is
anticipated that each PNC will have its own unique block of
host numbers assigned. In the case of manufactured PNCs, the
PNC host addresses will be assigned when the unit is
shipped. For homebrew units, a central registry will assign
the number. Since these numbers are 24 bits long, several
million numbers are available. The number merely identifies
the PNC address and is much like a hardware serial number.
It does not have to be changed when a PNC is sold or moved
or assigned a new callsign. (For those of you familiar with
the internet, an address resolution protocol is used to map
the PNC internet address numbers to the PNC callsign dynami-
cally.)
_R_o_u_t_i_n_g _o_n _t_h_e _N_e_t_w_o_r_k
Routing tables are automatically built and maintained
by network nodes. When first activated or after a system
reset, the PNC has no connections to neighboring stations.
Whenever a PNC has no connections it sends a broadcast bea-
con message periodically (probably every 10 minutes) until
_________________________
[3] Among other sources, Professor Jerome Saltzer of
MIT has implemented TCP/IP for the IBM PC. His imple-
mentation is available and can be reproduced at no
charge, although MIT retains the copyright.
[4] This is registered with the Defense Communication
Agency's Network Information Center as network number
044.xxx.xxx.xxx AMPRNET as documented in Internet RFC
870 dated October 1983.
- 6 -
it has established at least one connection to a neighboring
PNC. When a neighboring PNC receives such a beacon, it
attempts to open a connection to the PNC sending the beacon
message. Whenever any node-to-node network activity is
detected, routing tables are updated by all PNCs that
received the messages so that each will understand the most
recent network connectivity. Routing tables may also be
exchanged to provide updates.
If a PNC already in the routing table has not been
active for a length of time, a message is sent to that PNC
to check that it is still active. This is called _p_i_n_g_i_n_g,
and will probably be performed after 30 minutes of idle time
has elapsed.
If an attempt to communicate with a neighboring PNC
fails for any reason, whether during normal packet relaying
or as a result of a failed ping, that PNC is deleted from
the open connections list and routing table, and will no
longer be used for packet relay by the PNC detecting the
failure. Thus, the network will recover from and route
around any failure that does not isolate a node. When the
failed PNC recovers, its beacon or other activities will
alert its neighbors that it has returned to service.
Connections between PNCs need not be radio links.
Modems, hardwire lines, optical fibres, or other means will
serve as well. In these cases, the messages sent by the PNC
over these links are identical to those that would have
travelled over the AX.25 virtual radio circuit, so there
will be no difference in operation with these other types of
links.
_A_c_k_n_o_w_l_e_d_g_e_m_e_n_t_s
My deepest thanks to Mike Brock WB6HHV, for his invalu-
able suggestions on the design of the network, as well as
his help in preparing this document.
My thanks also to the many people of the Vancouver Ama-
teur Digital Computer Group and of Tucson Amateur Packet
Radio Inc, and to Phil Karn KA9Q, Rod Hart WA3MEZ, Harold
Price NK6K, and Skip Hansen WB6YMH for their contributions
and suggestions.
_R_e_f_e_r_e_n_c_e_s
Beattie, J. Gordon N2DSY. _N_e_t_w_o_r_k_i_n_g _C_o_n_s_i_d_e_r_a_t_i_o_n_s _f_o_r _t_h_e
_A_m_a_t_e_u_r _P_a_c_k_e_t _N_e_t_w_o_r_k
Borden, David W. K8MMO. _T_h_e _E_a_s_t_n_e_t _N_e_t_w_o_r_k _C_o_n_t_r_o_l_l_e_r
Bruninga, CDR Robert E. WB4APR. _E_a_s_t_n_e_t: _A_n _E_a_s_t _C_o_a_s_t
_P_a_c_k_e_t _R_a_d_i_o _N_e_t_w_o_r_k
- 7 -
Bruninga, CDR Robert E. WB4APR. _H_F _P_a_c_k_e_t_s: _M_o_d_e_m_s _a_n_d
_G_a_t_e_w_a_y_s
Fox, Terry WB4JFI. _I_S_O _R_e_f_e_r_e_n_c_e _M_o_d_e_l _R_e_v_i_e_w
Saltzer, Jerome A. _P_C/_I_P _U_s_e_r_s _M_a_n_u_a_l.
Tannenbaum, Andrew. _C_o_m_p_u_t_e_r _N_e_t_w_o_r_k_s.
TAPR, Inc. _T_N_C _U_s_e_r_s _M_a_n_u_a_l.
DARPA Internet RFCs are available from the Defense Communi-
cations Agency Network Information Center at SRI Interna-
tional, Menlo Park, CA. Many technical libraries also have
copies. Of special interest are numbers 765, 768, 791, 792,
793, 813-817, 826, and 870.