home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Black Box 4
/
BlackBox.cdr
/
hamradio
/
nosvw137.arj
/
NOSFILES.ZIP
/
NETROM.DOC
< prev
next >
Wrap
Text File
|
1991-09-18
|
21KB
|
521 lines
========== NOSview [137]
NETROM.DOC
==========
INTRODUCTION
------------
The NET/ROM support for the KA9Q package serves three purposes:
1. Existing NET/ROM networks may be used to send IP traffic.
2. NOS may be used as a NET/ROM packet switch.
3. NOS may be used to communicate with NET/ROM nodes, and its
mailbox facility can accept connects over the NET/ROM network.
SETTING UP THE NET/ROM INTERFACE
--------------------------------
No physical interface is completely dedicated to NET/ROM, which
is as it should be. You attach all your AX.25 interfaces, of
whatever sort. Then you attach the NET/ROM pseudo-interface
('attach netrom'). Then you identify to the NET/ROM software
those interfaces you want to allow it to use, with the 'netrom
interface' command.
The format of this command is:
-----------------------------------------------------------------
netrom interface tnc0 #GWA 192
-----------------------------------------------------------------
The first argument is the name of the previously attached
interface you want to use. The second argument is the alias of
your node, to be used in your routing broadcasts. The alias is
never used for anything else. The last number is the NET/ROM
quality figure. This is used in computing the route qualities;
it represents the contribution of this interface to the overall
computation. For a 1200 baud half-duplex connection, 192 is the
right number.
You need a 'netrom interface' command for every interface you're
going to use with NET/ROM.
TRACING ON THE NET/ROM INTERFACE
--------------------------------
If you want to trace your NET/ROM datagrams, don't try turning on
trace mode for the 'netrom' interface. Nothing will break, but
nothing will happen. You should trace the individual AX.25
interfaces instead.
ROUTING BROADCASTS
------------------
Once you have set up your interfaces, you need to set some
timers. There are two: the nodes broadcast interval timer, and
the obsolescence timer. These are set in seconds, like the smtp
timer. You should usually set them to an hour.
If your local NET/ROM nodes broadcast every hour, but you want to
do so every ten minutes, you can say:
-----------------------------------------------------------------
netrom nodetimer 600
netrom obsotimer 3600
-----------------------------------------------------------------
Every time the obsotimer kicks, the obsolescence counts for all
non-permanent entries are decremented by one. When the count for
an entry falls below five, it is no longer broadcast. When it
falls to 0, it is removed. The count is initialized at 6. These
will eventually be settable parameters; you can adjust them now
by changing the initializers for the variables in the source
file.
When you first come on the air, you can send out nodes broadcasts
to tell the local nodes that you are available.
Use the command:
-----------------------------------------------------------------
netrom bcnodes tnc0
-----------------------------------------------------------------
where tnc0 is the interface on which you want to send the
broadcast. Do this for every interface on which you want to do
this.
By default, the NET/ROM code does not broadcast the contents of
your routing table. This is as it should be, since usually we
just want to be the endpoints of communications rather than
relaying NET/ROM traffic.
If you want to be a switch station, include the command:
-----------------------------------------------------------------
netrom verbose yes
-----------------------------------------------------------------
in AUTOEXEC.NOS.
Sometimes you can hear broadcasts from nodes that can't hear you.
If your routing table gets filled with these unusable routes,
your node will grind to a halt. The solution to this is node
broadcast filtering, via the 'netrom nodefilter' command. There
is a filter list, which contains a list of callsigns and
interfaces. Then there is a filter mode, which indicates what to
do with the list.
If the filter mode is 'none', no filtering is done.
If it is 'accept', then only broadcasts from the indicated
stations on the indicated interfaces are accepted.
If it is 'reject', then all broadcasts except those from the
listed stations on the listed interfaces are accepted.
Because the NET/ROM code cannot at this time recognize unusable
routes and try alternates, the use of the filter command is
strongly recommended to restrict broadcast acceptance to those
nodes which you know you can reach.
THE NET/ROM ROUTING TABLE
-------------------------
The next NET/ROM commands are those used for maintaining the
routing table. They fall under the 'netrom route' subcommand.
'netrom route add' adds a permanent entry to the routing table.
Its format is:
-----------------------------------------------------------------
netrom route add #GWB NS9GWB-5 tnc0 192 NR9AAA-2
-----------------------------------------------------------------
This command adds an entry for NS9GWB-5, whose alias is #GWB,
route quality 192, via NR9AAA-2 on interface tnc0. Let's talk
about what this means.
NS9GWB-5 is the "target" node, the ultimate destination of your
packets routed by the NET/ROM network.
NR9AAA-2 is your neighbor, the NET/ROM node to which you pass the
packet to be forwarded. Since NR9AAA-2 may appear on more than
one interface (the callsign may be used by more than one NET/ROM
node on different bands), we specify that we are to use tnc0 to
send the packet.
With NET/ROM, like IP, we don't know exactly what route a packet
will take to its destination. We only know the name of a
neighbor which has indicated a willingness to forward that packet
(of course, the neighbor may be the destination itself, but
that's unlikely in our application).
NET/ROM sends the packet to the neighbor, with a network header
specifying our callsign and that of the ultimate destination (in
this case NS9GWB-5).
To drop the route to NS9GWA-5, you would type:
-----------------------------------------------------------------
netrom route drop NS9GWA-5 NR9AAA-2 tnc0
-----------------------------------------------------------------
To see the contents of your routing table, you may type:
-----------------------------------------------------------------
netrom route
-----------------------------------------------------------------
and to see the routing entries for an individual station you can
type:
-----------------------------------------------------------------
netrom route info NS9GWA-5
-----------------------------------------------------------------
You may not use an alias as an argument to the 'netrom route
info' command.
THE IMPORTANCE OF THE ROUTING TABLE
-----------------------------------
The NET/ROM routing table is analogous to the IP routing table:
if there is nothing in it, your NET/ROM traffic will not go out.
You must either manually enter a list of routes (perhaps via
AUTOEXEC.NOS) or wait to receive routing broadcasts from your
neighbors before your NET/ROM traffic will leave your station.
If you go to send packets via NET/ROM and nothing happens, even
if you have trace mode on, make sure that the destination node is
in your NET/ROM routing table. If sending IP traffic, double
check the ARP table for an appropriate NET/ROM ARP entry for the
destination node (see below for more information on the use of
the ARP table).
INTERFACING WITH NET/ROMS USING YOUR SERIAL PORT
------------------------------------------------
What if you have a NET/ROM node or nodes, and you'd like to
attach them to your computer via their serial interfaces, and use
NOS as a packet switch? It's very easy: you have to attach those
interfaces, using the 'attach asy' command, but specifying type
'nrs' instead of 'slip' or 'kiss'.
'nrs' is the NET/ROM serial framing protocol, which is like KISS,
but uses different framing characters and has an 8-bit checksum.
When you attach an nrs interface, it can be used for passing IP
datagrams or AX.25 frames over serial lines or modems. To use it
for NET/ROM, you have to identify it to the NET/ROM code just
like any other interface, with the 'netrom interface' command.
THE TIME TO LIVE INITIALIZER
----------------------------
The 'netrom ttl' command allows setting of the time-to-live
initializer for NET/ROM datagrams. A value of 16 is recommended
for most networks. Use more if you expect to go more than 16
hops. The default is 64.
The purpose of the ttl initializer is to prevent a packet from
getting caught forever in routing loops. Every router which
handles the packet decrements the ttl field of the network
datagram before sending it on, and when it reaches 0 it is
discarded.
USING NET/ROM SUPPORT FOR IP
----------------------------
Now you know all the commands, but how do we actually use NET/ROM
for IP communications? This takes three steps:
1. Setting up the IP routing table.
2. Setting up the ARP address table.
3. Setting up the NET/ROM routing table.
Setting up the IP Routing Table
-------------------------------
In all likelihood, you will use NET/ROM to gateway two IP
subnets. For example, station NS9GWA-5 in the diagram below is
the gateway for Region 41, and NS9GWB-5 is the gateway for Region
42.
Stations NR9AAA-2, NR9BBB-2 and NR9CCC-2 are conventional NET/ROM
switches.
The # names are NET/ROM aliases.
_________________________________________________________________
| |
| #BOB #GWA #GWB #LIZ |
| NS9BOB-5...NS9GWA-5 NS9GWB-5...NS9LIZ-5 |
| : : |
| : : |
| NR9AAA-2...NR9BBB-2...NR9CCC-2 |
| #AAA #BBB #CCC |
| |
| |
| <----Region 41----> <----Region 42----> |
| 44.131.41.xx 44.131.42.xx |
| |
|_______________________________________________________________|
Let's say we're on the Region 41 subnet, and we want to talk to
someone in Region 42. NS9BOB will have an IP routing table entry
like this:
-----------------------------------------------------------------
route add region42/24 tnc0 ns9gwa
-----------------------------------------------------------------
where 'region42' is defined in DOMAIN.TXT as:
-----------------------------------------------------------------
region42.ampr.org. IN A 44.131.42.00
-----------------------------------------------------------------
The routing table entry specifies that NS9GWA should get all
packets for the Region 42 subnet via interface tnc0.
The Region 41 gateway NS9GWA has this IP routing table entry:
-----------------------------------------------------------------
route add region42/24 netrom ns9gwb
-----------------------------------------------------------------
Now, when the IP layer at NS9GWA gets datagrams for Region 42, it
knows that they have to go via NET/ROM to NS9GWB. Notice that we
don't specify a "real" interface, like tnc0 or nr0, in the route
entry. The NET/ROM network layer will pick the right interface
based on its NET/ROM routing table (see below).
Setting up the ARP table
------------------------
As 'ns9gwb' is an IP address and not an AX.25 callsign, the
NET/ROM send routine called by the IP layer needs to map from
'ns9gwb' to an AX.25 address.
It does this via a manually added ARP entry:
-----------------------------------------------------------------
arp add ns9gwb netrom NS9GWB-5
-----------------------------------------------------------------
[The use of the ARP table for this purpose is a kind of fudge,
since there is no way to do automatic address resolution for
NET/ROM, and ARP messages are never sent or received for NET/ROM
nodes. However, the ARP table does contain precisely what we
have here: mappings from IP addresses to callsigns, and it saved
a lot of code to do it this way.]
Notice also that no digipeaters are ever specified in the ARP
table. (Use 'ax25 route' if you need to specify digipeaters).
Also, the callsign to which we are mapping is the final
destination of the packet, not the non-destination neighbor.
That neighbor will be picked based on the NET/ROM routing table.
Setting up the NET/ROM Routing Table
------------------------------------
To launch the packets towards the Region 42 gateway NS9GWB via
the conventional NET/ROM network, NS9GWA will need a NET/ROM
routing table entry.
For example:
-----------------------------------------------------------------
netrom route add #GWB NS9GWB-5 tnc0 192 NR9AAA-2
-----------------------------------------------------------------
NR9AAA-2 is the local NET/ROM node at the entry point to the
NET/ROM network, and will hopefully contain a routing table entry
for NS9GWB-5.
Also, NS9GWA needs to broadcast its own alias to the NET/ROM
network, so that a routing table entry finishes up in NR9CCC-2
(for use by NS9GWB and any other node wishing to contact NS9GWA).
To do this, NS9GWA needs the additional commands:
-----------------------------------------------------------------
netrom interface tnc0 #GWA 192
netrom route add #AAA NR9AAA-2 tnc0 100 NR9AAA-2
-----------------------------------------------------------------
So, as a summary, let's look at what happens when Bob sends a
packet to Liz.
1. By reference to DOMAIN.TXT, NS9BOB determines that NS9LIZ is
in Region 42. The IP table entry for subnet Region 42 specifies
that the packet should go to NS9GWA, and so the packet travels by
IP to the gateway.
2. NS9GWA receives the incoming IP packet addressed to Liz in
Region 42, and determines that it should go via NET/ROM to the
Region 42 gateway NS9GWB.
3. NS9GWA passes the packet to the NET/ROM send routine, and
that routine uses the ARP table to translate NS9GWB's IP address
to the callsign 'NS9GWB-5'.
4. NS9GWA then passes the packet to the NET/ROM routing code.
That code checks to see if the destination callsign NS9GWB-5 is
the same as that of any of its assigned NET/ROM interfaces; that
is, it checks to see if this node is the final destination for
the packet.
Since it isn't, it puts a network layer header on it, and looks
for NS9GWB-5 in its NET/ROM routing table.
5. Using the table entry, NS9GWA routes the packet to NR9AAA-2.
From there it travels to the Region 42 gateway NS9GWB (presumably
via NR9BBB-2 and NR9CCC-2).
6. When NS9GWB receives the incoming packet, it determines that
it has reached its final NET/ROM destination. Because NS9GWB is
a NOS node, not an ordinary NET/ROM switch, the packet is now
passed up to the IP layer.
7. The IP layer then discovers that the packet is destined for
Liz, and so routes it to her in the normal way.
THE NET/ROM TRANSPORT LAYER
---------------------------
NET/ROM transport is the protocol used by NET/ROM node to
communicate end-to-end. When a user attaches to a NET/ROM via
AX.25, and asks for a connect to a node in the NODES list, his
local NET/ROM tries to open a transport connection to the
destination node over the NET/ROM network. NET/ROM transport
packets are carried in NET/ROM network datagrams, just like IP
datagrams.
You shouldn't use NET/ROM transport when connecting to other
TCP/IP stations. TCP is a much better protocol than NET/ROM
transport, and makes better use of available bandwidth. Also,
BM/ELM and SMTP are more convenient to use than a TCP/IP
station's mailbox facility.
However, for communicating with AX.25 users via the NET/ROM
network, the transport facilities in NOS will work better (and
more easily) than the traditional method of connecting to your
local node via AX.25.
CONNECTING VIA NET/ROM TRANSPORT
--------------------------------
To connect to the node whose alias is #BBB and whose callsign is
NR9BBB-2, you can issue either of the following two commands:
-----------------------------------------------------------------
netrom connect #BBB
netrom connect NR9BBB-2
-----------------------------------------------------------------
If #BBB:NR9BBB-2 is in your NET/ROM routing table, your station
will transmit a connect request to the appropriate neighbor used
to reach NR9BBB-2.
NET/ROM transport sessions are very much like those for AX.25.
You can use the 'disconnect', 'reset', 'kick', 'upload' and
'record' commands, and the 'session' command to switch sessions.
DISPLAYING THE STATUS OF NET/ROM CONNECTIONS
--------------------------------------------
The command 'netrom status' is used to display the status of all
NET/ROM connections, which will include those used in keyboard
sessions as well as ones attached to the mailbox.
For more detailed information on a session, you can use the
address of the NET/ROM control block:
-----------------------------------------------------------------
netrom status <&CB>
-----------------------------------------------------------------
where <&CB> is the hex address given in the short form of the
'netrom status' command.
NET/ROM TRANSPORT PARAMETERS
----------------------------
The NET/ROM transport parameters may be set with the various
NET/ROM subcommands. Their meanings are listed below:
acktime: This is the ack delay timer, similar to the AX.25 T2
timer.
choketime: The time to wait before breaking a send choke
condition. Choke is the term for NET/ROM flow control.
irtt: The initial round trip time guess, used for timer setting.
qlimit: The maximum length of the receive queue for chat
sessions. This is similar to 'ax25 window'.
retries: Maximum retries on connect, disconnect, and data
frames.
window: Maximum sliding window size, negotiated down at connect
time.
THE MAILBOX
-----------
The AX.25 mailbox also accepts NET/ROM connections. The 'mbox
on' and 'mbox off' commands control whether the mailbox is turned
on for NET/ROM as well as AX.25, and the 'mbox' command displays
current mailbox connects of both types.
Many people have observed that the AX.25 mailbox requires the
user to enter a carriage return to bring up the banner and
prompt. This is because of certain defects of that protocol when
it is used as the link layer for several different higher level
protocols, and is unavoidable.
The NET/ROM mailbox does not require the carriage return, and
will be activated as soon as the incoming connection is made.
WHERE TO GO FOR MORE INFORMATION
--------------------------------
The paper "Transmission of IP Datagrams over NET/ROM Networks"
(by Dan Frank, W9NK) appeared in the Seventh ARRL Networking
Conference papers, available from the ARRL. There he describes
the more technical details of how the NET/ROM network support
works.
If you want to learn about NET/ROM, talk your local NET/ROM or
TheNET operator out of his or her manual. If you want to learn
more, read the source code.
There has been a great deal of controversy about TheNET, a no-
charge NET/ROM clone for TNCs. This is not the place to discuss
the truth of the charges leveled by Software 2000 against its
authors, but that situation has led to W9NK making the following
statement:
"The NET/ROM transport support in NET.EXE [NOS] was not taken in
any way, shape or form from NET/ROM (whose source I have never
seen) or from TheNET. The protocol code is based on protocol 6
from Tanenbaum's excellent book, "Computer Networks", as a
moderately careful reading of both should show. The source code
is freely distributed, so the curious reader should have the
opportunity to check this assertion if he or she so desires.
"The smoothed round trip time calculation, which is not done in
'real' NET/ROMs (and should be, by the way -- they'd work a whole
lot better) is adapted from that used by KA9Q in the TCP protocol
in NET. The dicey business of adapting it to a sliding windows
protocol with selective retransmission was done by me, all alone,
after my cries for help on the tcp-group mailing list went
unanswered :-).
"I have taken the precaution of copyrighting the NET/ROM code in
NET. It may be freely distributed for non-commercial purposes,
in whole or in part, and may be used in other software packages
such as BBS systems if so desired, so long as the copyright
notice is not removed from the source files, and the program in
which it is used displays 'NET/ROM code copyright 1989 by Dan
Frank, W9NK' when it starts up.
"Any person who wishes to distribute the code, or anything based
on the code, for commercial purposes will find me very
reasonable, but rather insistent about being compensated for the
hours I've spent working on it".