Date: 04 Jul 88 20:06 GMT
Message-ID: <1054@ON7RC>
From: ON7PC@ON7RC
To: ALL@BLGNET
Subject: NETROM + TheNet User Manual (1)
Path:       PI8HWB!ON1AWB!ON7RC


                                              July 2, 1988

     Hi folks,

     In May 1987 Mike Busch W6IXU and Ronald Raikes WA8DED
     writted a packet radio level 3 software called NET/ROM.

	We were the first in ON to try it  on July 1987 under
     the call ON7RC , and we appreciated very much this
     firmware.
	
     In April 1988 the german  NORD><LINK group  announced
     TheNet a public domain software, 100 % compatible with
     the NET/ROM V1.3.

	Now most of the ON-nodes are using TheNet.	

     If you are interrested in these state of the art
     networking, you will find here a reprint of the most
     important chapters of the original NET/ROM manual, plus
     some tips  from the TheNet.

     Take a hard copy of this file it may be useful !

     But how  to see the difference ? The only little
     difference is the prompt following the identification :    
     "}" is the prompt for NET/ROM and ">" is for TheNet ! 
	
     Feel free to try NET/ROM or TheNet, and we always
     appreciate your comments.

     Vy 73 from Pierre ON7PC 


NET/ROM and TheNet User'S Manual                           Part 1

-----------------------------------------------------------------
                             NOTICES
-----------------------------------------------------------------

NET/ROM  is a registerd trademark of Software 2000 Inc.,  1127
Hetrick Avenue, Arroyo Grande, California 93420 USA.Telephone
(805)489-1977

TheNet is public domain  of The Northern German Packet Group
NORD><LINK,  c/o Hans Georg Giese DF2AU,  Hinter dem Berge 5, 
D-3300 Braunschweig, FRG 

-----------------------------------------------------------------
                      THEORY OF OPERATION :
-----------------------------------------------------------------

Some terminology :
------------------

USER :  Any amateur packet radio station using AX25 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-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  :  Three 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.

DOWLINK  :  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-layer  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).

Making Connections :
--------------------
Suppose you are a user with access to a local node,  and you want 
to  contact another user station who is also within the range  of 
the same node.  You can,  of course, connect to the other station 
"the old way" by using the node as a digipeater.

Uplink-downlink connection :
----------------------------
To  take  advantage  of the store-and-forward capability  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  or  mnemonic 
identifier 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 can properly identify you as the connecting  user 
station,  and  is especially important when the destination is  a 
mailbox, gateway, or automated server.

Well ...  that's not EXACTLY the way it works!  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.

Uplink-crosslink-downling connection:
-------------------------------------
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  node, 
however, you would use a three-step procedure:

(1) connect to your local node; then,
(2)  issue  a  CONNECT  command with  the  callsign  or  mnemonic 
identifier 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  a  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 
hilltops...

Creating a "backbone" by using dual-channel nodes :
---------------------------------------------------
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 of 
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 RS232 cable.  Each TNC 
makes responsibility for handling traffic on a single  frequency; 
crossfrequency  traffic is passed over the cable between TNCs  at 
relatively high speed (e.g. 9600 bps).

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  requires  nothing   more 
elaborate than some isolation diodes.

-----------------------------------------------------------------
                      The CONNECT command :
-----------------------------------------------------------------

The connect command is used to request a circuit to another  node 
, a down link to another user, or a connection to the node's host 
terminal.

To request a circuit to another node, use :
     CONNECT node
where node must be the callsign or mnemonic identifier of another 
node  that  is "known" to this node.  (Use the NODES  command  to 
obtain  a list of all known node callsigns and identifiers.)  For 
example :
     CONNECT WB7BNI-1
     SAN:WA6AMT-4} Failure with PHX:WB7BNI-1

     CONNECT SFO
     SAN:WA6AMT-4} Connected to SFO:WA6AMT

To request a downlink to another user, use:
     CONNECT usercall [[VIA] digicall,...,digicall]
where usercall is the callsign  of the user station and  digicall 
is the callsign (or alias) of the digipeater.  If digipeaters are 
used,  the  use  of  "VIA"  is optional ("VI"  or  "V"  are  also 
acceptable).  Digipeaters  may  be separeted by either spaces  or 
commas. For example:
     CONNECT WM6MP via N6GPP-1
     LAX:WA6AMT-3} Busy from WM6P

     CONNECT W0RLI
     SFO:WA6AMT} Connected to W0RLI

To request a connection to the node's host terminal,  the command 
is:
     CONNECT
with no parameters. For example:
     CONNECT
     SBA:WA6AMT-2} Connected to SBA:WA6AMT-2

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 "Node  busy",  "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 blank line is entered before the requested connection 
is established.

-----------------------------------------------------------------
                      The NODES command :
-----------------------------------------------------------------

The NODES command is used to display or modify the node's routing 
table.

To  display  a  list  of other known nodes  with  their  mnemonic 
identifiers, use NODES without any parameter:
     NODES
     SAN:WA6AMT-4} Nodes:
     LAX:WA6AMT-3     SBA:WA6AMT-2     PRB:WA6-AMT-1
     SFO:W6AMT        RBL:WA6AMT-7     ONT:AA6TN-1
     LAS:K7WS-1       PHX:WB7BNI-1

The normal NODES display includes all knowm nodes in the  routing 
table  except "hidden nodes" that have mnemonic identifiers  that 
start  with the "#".  To obtain a display of all nodes  including 
such hidden nodes, use the command "NODES *":
     NODES *
     SAN:WA6AMT-4} Nodes:
     LAX:WA6AMT-3     SBA:WA6AMT-2     PRB:WA6-AMT-1
     #PRB:WA6AMT-11   SFO:W6AMT        #SFO:WA6AMT-10
     #WWORM:WB6FFC-1  #EWORM:WA3YMH-1  RBL:WA6AMT-7     
     ONT:AA6TN-1      LAS:K7WS-1       PHX:WB7BNI-1

To  display  specific routing information for a particular  node, 
use  NODES followed by the callsign or identifier of the node  in 
question:
     NODES PHX
     LAX:WA6AMT-3} Routes to PHX:WB7BNI-1
     > 108 6 0 AA6TN-1
       81 6 0 W6AMT-4

This command shows up to three routes to the specified node.  For 
each route, the following items are displayed:
     . the symbol ">" if the route is in use
     . quality of the route (255 is best, 0 is worst)
     . obsolescence count (0 denotes a locked entry)
     . port number (0=HDLC port, 1=RS232port)
     . path to the neightboring node (callsign + any digis)

The  nodes  command  support also manul updates  to  the  routing 
table,  but  this  capability  is  available only  to  a  cnotrol 
operator who has previously validated his credentials during this 
connection by successfully executing the SYSOP command. To add or 
delete routing table entries, the command are:
  NODES nodecall + ident quality count port neighbor [digicall
...]
  NODES nodecall - ident quality count port neighbor [digicall
...]

The  "+"  version  adds a new entry to  the  routing  table,  the 
callsign nodecall is added to the list of known nodes if it isn't 
already there.  The ident parameter is the mnemonic identifier up 
to six characters long, or "*" if the node has no identifier. The 
quality parameter is a decimal integer in the range 255 (best) to 
0  (worst) that defines the quality of the best-cae route to the 
destination node via the specified neighbor.  The count parameter 
is  the  initial obsolescence count - zero denotes  a  permanent, 
unchangeable route entry. The port parameter is given aseither 0 
(HDLC)  or 1 (RS232 port).  The neighbor and digicall  parameters 
give  a  path  to  an  adjacent  node  that  is  enroute  to  the 
destination (two digipeaters maximum).

The  "-"  version  searches the routing table for an  entry  that 
exactly matches the given nodecall,  port,  neighbor and digicall 
parameters,  and deletes it if such an entry is  found;  deleting 
the last route for a particular nodecall also removes it from the 
list  of  known node.  In case of an invalid request (or a  valid 
request  by  an unvalidated user),  those  commands  are  quietly 
ignored, not diagnosed.

Examples:
     NODES WB7BNI-1 + PHX 115 6 0 AA6TN-1
     LAX:WA6AMT-3} Routes to PHX:WB7BNI-1
     > 115 6 0 AA6TN-1
       81 6 0 W6AMT-4

     NODES WB7BNI-1 - PHX 81 6 0 W6AMT-4
     LAX:WA6AMT-3} ROUTES TO PHX:WB7BNI-1
     > 115 6 0 AA6TN-1
	
-----------------------------------------------------------------
                       The USERS command :
-----------------------------------------------------------------

The USERS command displays a summary of who is using the node:

     USERS
     LAX:W6AMT-3} NET/ROM 1.2 (720)
     Uplink(WA8DED)              <--> Host(LAX:W6AMT-3)
     Uplink(KA6SOX)              <--> Downlink(KA6SOX-15 WB6YMH)
     Uplink(NK6K-2)              <--> Circuit(SBA:W6AMT-2 NK6K-2)
     Circuit(SFO:W6AMT WB6ASR)   <--> Downlink(WB6ASR-15 WD6E)
     Circuit(SFO:W6AMT-2 WB6RAL) <--> Circuit(LAS:K7WS-1 WB6RAL)
     Circuit(SBA:W6AMT-2 WA6JPR)
     Uplink(NK6K)

The  heading  of the users display indicates the version  of  the 
NET/ROM  firmware in use at the node,  and the amount of free RAM 
space (shown in parentheses, and expressed as a number of 32-byte 
buffer segments).

After  the heading,  the USERS display shows the active  circuits 
and links, using the following formats:
     . uplink(fromcall)
     . downlink(fromcall tocall)  
     . circuit(othernode usercall)
     . host(thisnode)

The "<-->" symbols represent active "patchcords" in the node that 
connect uplinks, dowlinksn circuit and possibly the host terminal 
(if  any).  The  lines wich do not contain the  patchcord  symbol 
represent users who are in command mode at the node.

                                               Part 2 follows ...