opmerking van de sysop vooraf: ------------------------------ het ondertstaande artikel over netrom kwam ik tegen op de schijf van het packet-radio station van wim pe1fib in beek bij nijmegen. zo te zien heeft het bericht een lange weg afgelegd, voordat het op hcc-apeldoorn-1 terecht kwam. om niemand tekort te doen en/of niemand te beledigen, heb ik de volledige kop met de routing-informatie in tact gelaten. ron pe1hiz, sysop ber# tr lengte aan van @ bbs datum titel 1338 bn 29722 all pa0hwb pi8zaa 870731 tnc-2 net/rom via:pa0hwb van:db2os ber.nr:1709 rec:870730/1236 send:870731/1811 =============================================================================== <-> manual pwg forwarding van dj7ka-2 (tuebingen) 24/07/87 door on1gl <-> =============================================================================== msg # 1319 type:b stat:$ to: alle @alle from: df2oo date: 11-feb/2255 subject: tnc-2 net-rom (wichtig!) bulletin id: netrom01 von df2oo/dg3saj #2574/brigachtal (jn48fa)/rx:870211-2014/tx:870211-2249 packet-access from db2os 04.02.87 23:34 utc net/rom level 3/4 fuer tnc-2 subj: net/rom level 3-4 node w6ixu/ke6bx/3799/hollister, ca/870113/1024z /w6ixu//arroyo grande ca/monday 12-jan-87 at 7:30 pm notice to all users of the w6amt digipeater system ================================================== the w6amt digipeater system is starting a test of "net/rom", which is a new firmware package for the tnc-2 which supports state-of-the-art networking capabilities (commonly referred to in packet radio circles as "layer 3" and "layer 4"). net/rom was installed at the w6amt-2 and w6amt-3 sites on january 11, 1987. we hope to install the new firmware at w6amt-0, w6amt-1, and w6amt-4 during the next couple of weeks. (installation at w6amt-7 will have to wait until spring, due to inaccessibility of the site.) the following information about net/rom is provided in order to enable users of the w6amt system to participate in the test by utilizing the new capabilities. participating users should keep in mind that net/rom is still in a highly experimental stage. please report problems by leaving a message for wa8ded on the w6ixu multibox. users who do not with to participate in the net/rom test may continue to use the w6amt digipeater system in the usual fashion, since the new firmware supports ordinary ax.25 digipeating. overview of net/rom =================== introduction ------------ net/rom is a firmware replacement which transforms a standard tapr tnc-2 (or "clone") into a state-of-the-art network node controller. it is intended for use primarily on hilltops and other wide-coverage digipeater sites. it is not appropriate for end-user or mailbox stations. a net/rom node provides the normal functions of an ordinary ax.25 digipeater, plus a set of sophisticated higher-level networking capabilities. a user may connect to a nearby net/rom node; display a list of other known network nodes; establish a transport-level circuit to a distant node; and connect to another end-user or mailbox in the vicinity of the distant node. compared with conventional ax.25 multi-hop digipeating, net/rom's true store-and-forward packet switching technology can provide an order-of-magnitude improvement in throughput, especially over long paths. routing from the local node to the distant node is handled automatically, and even includes alternate routing to circumvent network outages. net/rom supports cross-frequency and cross-band networking without the need for exotic multi-port digipeater hardware. a dual-channel node, for example, is implemented simply by installing net/rom in a pair of standard tnc-2s and connecting them together with an rs232 cable. a three- or four-channel node can be created by connecting multiple tnc-2s together, using a simple diode-matrix coupler. net/rom was developed by ron raikes (wa8ded) and mike busch (w6ixu) of software 2000, inc. functional highlights --------------------- runs on ordinary tnc-2 hardware net/rom is unique because it provides state-of-the-art networking capabilities without the need for special hardware. net/rom runs on a standard tapr tnc-2 terminal node controller, or on any of the commercially-available tnc-2 "clones". net/rom is distributed in the form of a 27c256 eprom which simply plugs into the rom socket of the tnc-2 in place of the standard tapr firmware rom. store-and-forward packet switching instead of multi-hop digipeating, net/rom provides true store-and-forward packet switching. the result is significant improvement in throughput and reliability. on long paths (three or more digipeaters), dramatic improvements are possible. for instance, the calculated speed improvement for the los angeles/san francisco route (four digipeaters) assuming typical 1200-baud vhf network conditions is about 800%! two-levels of error and flow control net/rom uses the standard ax.25v2 packet radio protocol for links between neighboring nodes, as well as for links from each node to its local users. normal ax.25v2 error handling is used to assure error-free transmission, and normal ax.25v2 flow control is used to manage network congestion. in addition, net/rom incorporates a transport-level "sliding window protocol" to provide end-to-end error and flow control for each virtual circuit. end-to-end error control protects against lost, duplicate, or out-of-sequence frames resulting from node failures and dynamic routing changes. end-to-end flow control protects the network against disproportionate loading by any one circuit. multi-channel capability without special hardware net/rom supports multi-frequency operation without the need for exotic multi-port digipeater hardware. a dual-channel node, for example, consists simply of a pair of standard tnc-2s (with net/rom in each) connected together with a simple rs232 cable. configuring a net/rom node for three or four channels is almost as easy: a tnc-2 is used for each frequency, and the multiple tncs are interconnected via their rs232 ports using a simple diode-matrix coupler. automatic adaptive routing net/rom automatically takes care of the routing of traffic between one node and another. a user needs to specify just the desired destination, not the route. each node keeps track of the other nodes in the network and the various possible paths that may be used to reach them. if a node or path becomes unusable due to equipment failure or poor propagation, net/rom automatically switches to an alternate route (if available) to circumvent the outage. conversely, when a new node is placed on-line, other nodes automatically incorporate the new node into the network routing structure. such routing changes are handled dynamically, without disrupting user connections in progress. local, remote, and automatic routing updates net/rom supports three methods of updating its routing information: local, remote, and automatic. initial routing information is entered manually by an on-site operator using a local terminal. routing changes may be made remotely by a control operator over an ordinary packet radio connection--a randomized verification algorithm effectively prevents changes by unauthorized operators. in addition, net/rom nodes broadcast routing information to each other on an hourly basis, thereby enabling the network to incorporate new nodes and to bypass outages in real-time without manual intervention. very easy to use despite its internal sophistication and advanced networking capabilities, net/rom is exceptionally easy to use. there are only two commands that a user needs to learn: nodes to obtain a list of other net/rom nodes, and connect to establish crosslinks to other nodes or downlinks to other user stations. compatible with existing digipeaters each net/rom node also supports the functions of an ordinary ax.25 digipeater. users need not make use of the high-level networking functions of net/rom unless they want to. digipeater owners can upgrade their sites to net/rom nodes without disrupting users. multi-channel net/rom nodes provide multi-port digipeating as well. a usage example =============== you are ka6pre ("packet radio enthusiast") located in san diego, and you want to access the w0rli bulletin board system in santa cruz (near san francisco). from past experience, you know that a digipeated ax.25 connection requires four digipeaters and is practically unusable. the local w6amt-4 digipeater on 145.01 was recently upgraded to a net/rom node, however, so this time you decide to try using the high-tech method. first, you establish an uplink to your local node, using the normal connect command provided by your tnc: }c cmd: connect w6amt-4 *** connected to w6amt-4 next, you ask the local node for a list of other net/rom nodes for which it has routing information, using the nodes command: nodes w6amt-4| nodes: w6amt-3 w6amt-2 w6amt-1 w6amt w6amt-7 aa6tn-1 you know that w6amt-0 serves the san francisco area (it was always the last digipeater you used to reach w0rli via ax.25), so you ask your local net/rom node to connect you to w6amt: connect w6amt w6amt-4| connected to w6amt you are now talking to the san francisco node, and you could issue another nodes command to see a list of other nodes that it knows how to reach. in this case, however, you simply want a connection to the w0rli bbs, so you ask for it: connect w0rli w6amt| connected to w0rli hello fred, welcome to w0rli bbs at 0532z ka6pre-15 de w0rli> etc. note that the downlink from w6amt to w0rli has been made using your callsign (ka6pre), but with the ssid suffix changed from -0 to -15. (more about this later.) at the conclusion of your session with w0rli bbs, you simply disconnect your tnc as usual: }c cmd: disc *** disconnected cmd: when you disconnect, your local node (w6amt-4) automatically disconnects your circuit to w6amt, and the w6amt node automatically disconnects your downlink to w0rli. theory of operation =================== some definitions ---------------- following are definitions of some terms that are used in describing the operation of net/rom. user -- any amateur packet radio station using ax.25 protocol. in the context of this document, a bbs or other automated server is considered a "user". digipeater -- a station capable of digitally repeating ax.25 frames as specified in the ax.25 protocol specification. generally, refers to an unattended, wide-coverage digital repeater, often located on a hilltop. node -- a packet radio station utilizing tnc-2 hardware executing net/rom firmware. generally, refers to an unattended, wide-coverage station, often located on a hilltop. dual-channel node -- a pair of net/rom nodes operating on two different frequencies, and coupled together by means of an rs232 cable. multi-channel node --jthree or more net/rom nodes operating on different frequencies, and interconnected via their rs232 ports using a diode-matrix coupler. link -- an ax.25 connection involving a node at one or both ends. node-to-node links always use ax.25v2 protocol. user-to-node links use ax.25v2 protocol if the user's tnc supports it, otherwise ax.25v1. uplink -- an ax.25 connection between a user and a node, initiated by the user. an uplink is usually a direct connection, but may be digipeated if necessary. downlink -- an ax.25 connection between a node and a user, initiated by the node. a downlink is usually a direct connection, but may be digipeated if necessary. a downlink is established by a node at the behest of a user (in response to a connect command). crosslink -- an ax.25 connection between two adjacent nodes. a crosslink is usually a direct connection, but may be digipeated if necessary. a crosslink between two nodes is initiated by one of the nodes when first establishing a circuit which traverses the route segment between the two nodes. one crosslink can carry any number of circuits, so it is never necessary to have more than one crosslink between any pair of nodes. circuit -- a transport-level connection between two nodes, established by one of the nodes at the behest of a user (in response to a connect command). the two nodes are not necessarily adjacent, and may be quite distant. the circuit is automatically routed through intermediate nodes as necessary, and carried from node to node over crosslinks (which are initiated if not already established). digipeating vs. store-and-forward --------------------------------- the ax.25 protocol was originally designed for point-to-point (non- digipeated) connections. ax.25 was subsequently extended to accomodate one digipeater, and later extended again to allow up to eight digipeaters. as all experienced packet radio users know, however, ax.25 is practically unusable for communications on paths exceeding two or three "hops". the reason for this is that ax.25 digipeaters do not participate in error control. for an ax.25 packet to traverse a multi-hop path, it must not fall victim to a collision or other error during any of the hops; otherwise, it must be retransmitted by the originating station and start its journey all over again. the probability that an ax.25 packet can complete its journey successfully deteriorates rapidly as the number of hops increases. for example, it takes five hops (four digipeaters) to get from los angeles to san francisco. if the average reliability per hop is 90% (which may be optimistic in those congested areas), then the probability that a packet will traverse the five-hop path unscathed and be successfully acknowledged (which requires ten error-free hops) is less than 35%. in other words, it will take an average of 2.9 tries to get the packet through successfully. since the usual timeout threshhold for a five-hop path is 36 seconds, the average elapsed time to get the packet through will average about 77 seconds! Ûthis assumes a 10% error probability per hop, and the usual 1200-baud timeout of 4*(2*digis+1) seconds.| using net/rom nodes instead of ordinary ax.25 digipeaters changes this situation dramatically for the better. when the los angeles user transmits a packet destined for san francisco, it is received by the local net/rom node serving los angeles. that node immediately passes the packet to its neighboring node to the north, and sends an acknowledgement back to the user. this process is repeated five times in all. whenever a packet is lost due to collision or other error, recovery is handled by just the two adjacent nodes involved. as a result, the average elapsed time to get a packet through decreases to less than 10 seconds, about an 800% improvement in throughput. Ûsame assumptions as previous example.| for longer paths, the payoff is even more dramatic. uplinks, downlinks, and crosslinks ---------------------------------- suppose you are a user with access to a local node, and you want to contact another user station who is also within range of the same node. you can, of course, connect to the other station "the old way" by using the node as a digipeater. to take advantage of the store-and-forward capabilities of the node, however, you would use this two-step procedure: (1) connect to the node ("uplink"); then, (2) issue a connect command with the callsign of the other user station ("downlink"). all ax.25 frames include the callsigns of both the originating station and the destination station. when you request a downlink, the node "adopts" your callsign as the originating station (rather than using its own callsign). this is necessary so that the destination station can properly identify you as the connecting user station, and is especially important when the destination is a mailbox, gateway, or other automated server. well...not exactly! if the node truly did "adopt" your callsign, and if there also happened to be a direct path (however marginal) between your station and the destination station, that station would then be "in range" of two stations using the same callsign. this can create serious confusion, ax.25-protocolwise! to avoid this problem, the downlinking node "adopts" your basic callsign, but changes the ssid (the "-n" callsign suffix) from n to 15-n. for example, if your callsign is k6aaa, the downlink uses k6aaa-15; if your callsign is w3abc-2, the downlink uses w3abc-13; and so forth. now, suppose you want to contact a user station that can't copy your local node, but is in range of another node that serves his area. once again, you could use "old-style" multi-hop digipeating to reach him (since every node is also a digipeater). to utilize the full store-and-forward capability of the nodes, however, you would use a three-step procedure: (1) connect to your local node; then, (2) issue a connect command with the callsign of the distant node; finally, (3) issue a connect command with the callsign of the other user station. when you perform step (2) of this procedure, you are asking your local node to create a "circuit" for you between your local node and the distant node. if the two nodes are sufficiently far apart, the circuit may have to pass through several intermediate nodes. in any case, the routing is performed automatically by the node. your circuit is carried by a series of ax.25 "crosslinks" between pairs of adjacent nodes. in all likelihood, the necessary crosslinks are already established when you issue your connect command (one crosslink can carry many circuits); if not, then the necessary crosslinks are set up. all of this crosslinking stuff happens automatically and transparently--you needn't worry about it, but it's interesting to know what's going on up there on the hilltops! error and flow control ---------------------- net/rom uses the standard ax.25v2 packet radio protocol for crosslinks between neighboring nodes, as well as for links from each node to its local users. normal ax.25v2 error handling is used to assure error-free transmission, and normal ax.25v2 flow control is used to control network congestion. in addition, net/rom incorporates a transport-level "sliding window protocol" to provide end-to-end error and flow control for each virtual circuit. end-to-end error control is necessary to protect against lost, duplicate, or out-of-sequence frames resulting from node failures and dynamic routing changes. end-to-end flow control is necessary to protect the network against disproportionate loading by any one circuit. the transport-level protocol used by net/rom is similar in concept to the familiar ax.25, but is somewhat more sophisticated. for example, it can accept out-of-sequence frames and re-sequence them internally. it can also selectively request a repeat of a missing frame without requiring retransmission of all succeeding frames. network routing --------------- when you ask one node for a circuit to a distant node, your connect command specifies the callsign of the destination node, but the routing is handled automatically by net/rom. automatic routing is handled by the routing manager, and is controlled by its routing table. the routing table within a node is a list of all the destination nodes "known" to this node. you can ask to see this list by using a parameterless nodes command. the routing table can keep track of a relatively large number of other nodes. if you want to connect to an especially distant node, it is possible that your local node doesn't know of it (i.e., it is not listed in the local nodes display). in this case, you can use connect to obtain a circuit to a known node nearer the desired destination, and then issue another nodes command to get a list of the nodes known to that node. this process can be repeated if necessary. for each known node, the routing table contains one or more known routes to that node. in this case, a "route" is simply a crosslink path to an adjacent node that is closer to the ultimate destination. the crosslink path usually consists of just the callsign of the adjacent node, but may also include one or more (ugh!) digipeaters if necessary. observe that the routing table does not contain the entire route to each known destination (this is unnecessary, and would require too much memory), but just a list of adjacent nodes that are reasonable choices for a next hop enroute to the destination. you can ask to see this list by using a nodes command specifying the callsign of the destination. if a node or path becomes unusable due to equipment failure or poor propagation, the routing manager automatically switches to an alternate route (if available) to circumvent the outage. such routing changes are handled dynamically, usually without disrupting circuits in progress. routing table updates --------------------- since each node keeps track of many other nodes and the available routes to those nodes, it is important that this routing information be kept up-to-date to reflect the current state of the network. net/rom supports three methods of updating its routing tables: local, remote, and automatic. when a node is first placed on-line, an initial set of routing information is entered manually by a control operator using a local terminal connected to the rs232 host port. routing changes may be made remotely by a control operator over an ordinary packet radio connection. a randomized verification algorithm effectively prevents changes by unauthorized operators. to enable the network to incorporate new nodes and to bypass extended outages without the need for control operator intervention, net/rom also provides a mechanism for automatic update of routing information on a distributed basis. about once per hour, each node automatically broadcasts a list of all other nodes which it knows how to reach. (this broadcast takes the form of an ax.25 ui-frame addressed to "nodes" with pid='cf'.) when this broadcast is received by neighboring nodes, they automatically make any necessary additions to their routing tables, and incorporate them into their own hourly broadcasts. thus, whenever a new node is placed on-line, knowledge of the new node automatically propagates throughout the network within a few hours. station identification ---------------------- in order to conform with fcc regulations concerning station identification, each net/rom node identifies itself every 9 minutes and 59 seconds. the station identification is carried by an ax.25 ui-frame addressed to "id" and containing the text "network node". digipeating ----------- of course, each node also supports the functions of an ordinary ax.25 digipeater. users need not make use of the high-level networking functions of net/rom unless they want to. digipeater owners can upgrade their sites to net/rom nodes without notifying the user population--the users won't notice any change unless they happen to monitor a station-id broadcast or try to connect to the node (expecting a "busy" message). furthermore, each multi-channel node is also a multi-port digipeater. each channel is assigned a different callsign. often, the same basic callsign will be used, but with different ssid suffixes for each frequency. (for example, n6net-1 on 145 mhz and n6net-11 on 220 mhz.) cross-frequency digipeating is requested simply by including both callsigns as digipeaters (e.g., "c w6zzz via n6net-1,n6net-11,..."). users of distant mailboxes, gateways, and other automated servers have two options: they can connect "the old way" (via multi-hop ax.25) or "the new way" (via the uplink-crosslink-downlink procedure). both methods will work with all existing bbss. auto-forwarding mailbox systems will have to use "the old way" until such time as their auto-forwarding algorithms have been updated to take advantage of net/rom. dual- and multi-channel operation --------------------------------- to realize the full potential of net/rom's high-level networking capabilities, it is an excellent idea to minimize interference between local (uplink/downlink) and long-haul (crosslink) traffic. one good way to accomplish this is to reserve one radio frequency exclusively for inter-node traffic, to provide end-user access to the nodes on one or more separate frequencies, and to discourage (ideally, to prevent) end-users from using the inter-node "backbone" frequency. this approach requires network nodes that can access two or more frequencies. net/rom supports such multi-channel operation without the need for exotic multi-port digipeater hardware. a dual-channel node, for example, consists simply of a pair of standard tnc-2s (with net/rom in each) connected together with a simple rs232 cable. each tnc takes responsibility for handling traffic on a single frequency; cross-frequency traffic is passed over the cable between tncs at relatively high speed. configuring a multi-channel net/rom node for three or more channels is almost as easy as dual-channel operation. a tnc-2 with net/rom installed is used for each frequency. once again, the tncs are interconnected via their rs232 ports. interconnecting three or more tncs in this fashion requires nothing more elaborate than some isolation diodes. commands ======== there are just two user commands: connect and nodes. the entire command verb ("connect") or just a fragment ("conn" or "co" or "c") is allowed. any command parameters must be separated from the verb and each other by one or more spaces. the maximum command length is 80 characters (anything more is ignored). commands must end with a carriage-return. connect command --------------- the connect command is used to request a circuit to another node, a downlink to another user, or a connection to the node's host terminal. to request a circuit to another node, the command is: connect nodecall where "nodecall" must be the callsign of another node that is "known" to this node. use the nodes command to obtain a list of all known node callsigns. to request a downlink to another user, the command is: connect usercall ÛÛvia| digicall,...,digicall| where "usercall" is the callsign of the user station, and "digicall" is the callsign of a digipeater. if digipeaters are used, the use of "via" is optional ("vi" or "v" are also acceptable). callsign parameters may be separated by either spaces or commas. to request a connection to the node's host terminal, the command is: connect with no parameters. in all cases, a successful connection is announced by the message "connected to (callsign)". "failure with (callsign)" indicates that the specified node or user did not respond after a number of attempts. "busy from (callsign)" indicates that the node or user responded but refused the connection request. other possible error messages are "user table full", "circuit table full", "link table full", and "host table full". these messages indicate a lack of resources in the node--the user should disconnect and try again later. an in-process connect command is immediately aborted if another command or a blank line is entered before the requested connection is established. nodes command ------------- the nodes command is used to display the node's routing table. to display a list of other nodes known to this node, the command is simply: nodes to display specific routing information for a particular node, the command is: nodes nodecall where "nodecall" must be the callsign of a known node. this command displays the transport-level timeout period (in seconds), plus a list of routes for the specified destination. for each route, the following information is displayed: port number (0=hdlc, 1=rs232), callsign of the adjacent node, and any necessary digipeaters (maximum of three). command interpreter messages ---------------------------- the following messages may be displayed by the command interpreter: connected to (callsign) busy from (callsign) failure with (callsign) invalid command invalid callsign circuit table full link table full host table full user table full routing table full limitations =========== the following limits apply to the "alpha-test" version of net/rom, and will probably be increased (possibly doubled) in the final release version: * maximum number of links per node: 20 * maximum number of circuits per node: 16 * maximum number of other known nodes: 32 * maximum number of command interpreter tasks: 8 17-jan-87 23:46:32 for those who may be following along, net/rom firmware went up at two more nodes of the w6amt system today. we now have a four node network operating with layer 3 (automatic routing) and layer 4 (virtual circuits with storeand-forward packet switching) as follows: w6amt-0 -- san francisco bay area w6amt-1 -- monterey bay area w6amt-2 -- santa barbara/san luis obispo area w6amt-3 -- los angeles area a fifth node, w6amt-4 in the san diego area should come on-stream next week. tonight, the network is working astonishingly well under extraordinary heavy load. we are delighted with the performance of the alpha-test firmware so far, and expect the beta-test firmware (with many enhancements) to be ready in about three weeks.