>Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP >Posting-Version: version B 2.10.1 6/24/83; site sdccsu3.UUCP >Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!zehntel!hplabs!sdcrdcf!sdcsvax!sdccsu3!brian >From: br...@sdccsu3.UUCP (Brian Kantor) >Newsgroups: net.ham-radio >Subject: Packet Radio Networking Proposal (long paper) >Message-ID: <2...@sdccsu3.UUCP> >Date: Sun, 26-Aug-84 13:00:52 EDT >Article-I.D.: sdccsu3.2220 >Posted: Sun Aug 26 13:00:52 1984 >Date-Received: Fri, 31-Aug-84 02:34:33 EDT >Distribution: na >Organization: UCSD beer & pizza society >Lines: 474 >Xref: dummy dummy:1 >X-OldUsenet-Modified: added Xref 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 ---------- 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. 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 community. 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 digipeaters, 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. The Network Solution 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 gateway 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. 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. The User View of the Network 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 + Who's On Listing + Network Status + Time and Date Server + Site Security Monitor - 4 - Network Protocols 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 transport 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 AX.25 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 AMTOR 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 Internet TCP/IP 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.) Routing on the Network 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 pinging, 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. Acknowledgements 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. References Beattie, J. Gordon N2DSY. Networking Considerations for the Amateur Packet Network Borden, David W. K8MMO. The Eastnet Network Controller Bruninga, CDR Robert E. WB4APR. Eastnet: An East Coast Packet Radio Network - 7 - Bruninga, CDR Robert E. WB4APR. HF Packets: Modems and Gateways Fox, Terry WB4JFI. ISO Reference Model Review Saltzer, Jerome A. PC/IP Users Manual. Tannenbaum, Andrew. Computer Networks. TAPR, Inc. TNC Users Manual. 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. -eom