HAM Radio 1

home *** CD-ROM | disk | FTP | other *** search

/ HAM Radio 1 / HamRadio.cdr / misc / tn208 / tn208.doc < prev next >

Wrap

Text File | 1991-03-04 | 20.7 KB | 425 lines

\*****************************************************************************/ ;* */ ;* */ ;* */ ;* ***** ***** */ ;* ***** ***** */ ;* ***** ***** */ ;* ***** ***** */ ;* *************** *************** */ ;* ***************** ***************** */ ;* *************** *************** */ ;* ***** ***** TheNet and TheNet Plus */ ;* ***** ***** Portable. Compatible. */ ;* ***** ***** Public Domain */ ;* ***** ***** NORD><LINK */ ;* */ ;* This software is public domain ONLY for non-commercial use */ ;* */ ;*****************************************************************************/ ;*****************************************************************************/ ;* */ ;* */ ;* */ ;* THENET PLUS NODEOP MANUAL */ ;* Version 2.08 */ ;* */ ;* March 1991 */ ;* */ ;* ************************************************** */ ;* */ ;* */ ;* */ ;* */ ;* */ ;* */ ;* */ ;* */ ;* */ ;* *************************************** */ ;* ********************************* */ ;* */ ;* */ ;* Programming: William A. Beech, NJ7P */ :* Documentation: Jack Taylor, N7OO */ ;* Editing: Neil Petersen, WD9DQH */ ;* */ ;* ************* */ ;* ********* */ ;* */ ;* */ ;* */ ;* */ ;* */ ;*****************************************************************************/ TNP2.08 UPDATE (A supplement to TNPLUS206.DOC) TheNet Plus version 2.08 incorporates several additional features over those found in version 2.06. For a detailed understanding of NodeOp considerations, the NodeOp manual as presented in the TN206.DOC file should be consulted. This file was included with the version 2.06 distribution. TNP2.08 has the following features over those found in TheNet version 1.0: *1. Aliases have replaced callsigns in the node ROUTES list. 2. "Not found <aliascall>" response to an unknown node (instead of a nodes dump). 3. (B)ye command added. 4. (H)eard command added (lists up to a max of 20 users over a 15 minute period). 5. INFO section completely SYSOP settable. 6. TXD is remotely SYSOP settable. 7. STA LED lights when a user connects to the node. 8. ON - OFF remote control feature added. 9. SYSOP KEY commands allow keying node radio with mark, space, or diddle alignment tones. 10. Both L2 and L3 network management capabilities are available. 11. The lengthy Parameter command response has been shortened to those parameters most commonly used during remote situations. 12. The SYSOP Password routine has been modified (in conjunction with the new SET208.EXE utility) and is more versatile than that found in version 2.06 13. A Parameter has been added to allow/disallow node broadcasts (beacons) on either the RS-232 or HDLC (radio) ports. 14. A Parameter has been added to allow/disallow the propagation of the # (hidden) nodes. 15. A Parameter has been added to allow/disallow CONNECT commands. Features 10 through 15 above are new with version 2.08. The emphasis of these new features is aimed at giving NodeOps and network managers the tools necessary for them to configure their systems to conform with local policy. * Included with this distribution is a varient ROM image which has BOTH call- signs and aliases in the ROUTES list. This feature was requested by a group which uses the same #node alias throughout their backbone trunking system. The 208B.ROM file ("B" for backbone) otherwise has all the features of version 2.08. NETWORK MANAGEMENT - BACKGROUND To a large extent, most of todays amateur packet node network has just "happened". From local region to local region, public spirited individuals and groups have patched together the network. This has been primarily driven by a desire to facilitate BBS activities. Unfortunately the user applications (increase in BBS bulletin activity, TCP/IP) have grown at a much greater rate than the network's capability to handle the additional traffic. This situation leaves the network builders with the following options: 1. Ignore the problem. 2. Upgrade the system. 3. Apply network management techniques. Up to now, most of our effort has been concentrated on option #1. Many of us would like to upgrade the system, but are hindered by a lack of general knowledge and by the expense of doing this. Due to both a lack of knowledge and lack of node capability, option #3 has not been generally pursued. How- ever if the future growth of our network is to be healthy, it is important we learn and apply, network management. Otherwise our upgrade attempts are apt to just end up with a larger congested system. A system which in turn will require additional upgrades sooner than necessary. While network management techniques will not stop the desirability of adding a system upgrade, they will allow us to use our present resources more wisely. Here are a couple examples of network management: The Southern Ontario Packet Radio Association (SOPRA) is blessed by having professional network types within their organization. They surveyed the coverage area in the Toronto area to determine what kind of system would be necessary to serve their membership. Today they run a relatively closed system. It consists of a 9600 baud backbone trunk tying together 5 or 6 1200 baud LAN nodes. They have ONE multiport BBS which adequately serves all of the members. They disallow all TCP/IP nodes. This doesn't mean they are anti-TCP/IP per se, but recognized such activity could overwhelm their system. By the same token, they recognized several BBSes within the same area is not very efficient due to the multiple forwarding (and hence, higher network usage) that needs to take place between them. Today the SOPRA system is performing quite nicely. A user can connect through- out the network reliably with little fear of being prematurely disconnected. Stepping into the outside world from their system, this situation dramatically changes! One finds the usual simplex hodge-podge overwhelmed with too many BBSes and IP nodes. The SOPRA group obviously defined the purpose of their system was to serve their member users, as efficiently as possible, with a BBS and ragchew capability. They shaped their network to support this goal. The main tool allowing them to prevent outside encroachment from diluting their system was a specially designed node chip. This chip has the capability to ignore uncoordinated nodes. In the densely populated Los Angeles area, portions of the network are designed to support BBS forwarding. Most of the NodeOps are also BBS SysOps and use the same specially designed node chip to promote this activity. Uncoordinated nodes, as a result, rapidly become history. Without this tool, the forwarding networks would soon saturate with multi-user activity. Version 2.08 now has this network management capability. This is a powerful tool and like anything else, is capable of being misused. NodeOps and net- work managers should carefully use it ONLY to support the purpose and integrity of their local system. L2/L3 CALLSIGN DISALLOWANCE Here is how it works: TheNet has two logical ports, port 0 (the radio port) and port 1 (the RS-232 port). In version 2.08 two additional ports have been added, ports 2 and 3. These ports don't go anywhere. If calls are assigned to these ports, they don't go anywhere either. Port 2 is designed to be SSID specific and port 3 is effective with any SSID. Assume we have a "rogue BBS" from an outside area who insists on forwarding through our network. He has been contacted and advised it would be a much more efficient use of the network to instead forward from one of our local BBSes. He refuses to honor our request. It is then agreed this station should be disallowed from our portion of the network. At the version 2.08 node nearest to the "rogue" we would go into the SYSOP mode and perform the following command: R 2 <callsign with ssid> + 0 (To disallow a specific callsign/ssid) or, R 3 <callsign> + 0 (to disallow this callsign with ANY ssid) If this is a non-node callsign, it will be prevented entry to the node immediately unless it is currently connected. If the callsign is connected when the entry is made, it will be prevented access upon a subsequent connect attempt. Following this entry, non-node callsigns will also be disallowed from being listed on the Heard list. Callsigns associated with nodes will similarly be treated with the exception that the aliases will decrement out of the node and/or routes tables in a normal manner following posting. It is recommended port 2 be used for node and port 3 for non-node callsigns. The entries of the disallowed calls will show in the routes list during SYSOP control, but otherwise will not be seen. If after due consideration, the "rogue BBS" decides he wants to make efficient use of the network and forward with a local BBS, he can be removed from the port 2/3 list by the SYSOP command: R 2 <callsign with ssid> - 0 or, R 3 <callsign> - 0 PARAMETER STRING In viewing hundreds of node responses to the Parameter command from around the country, it was noted that from node to node, many of those in the normal 26 parameter string are identical. As additional features were added to TheNet Plus, it required additional parameters be added. As a result, version 2.06 has a rather formidable looking parameter string composed of 30 groups. With version 2.08, this string has been reduced to 16 groups. This doesn't mean the "missing" parameters have gone away. They are still available to be custom set with the SET208.EXE utility prior to programming the node chip, if the NodeOp desires to change the existing default values. But under normal circumstances, these parameters are rarely changed. The parameters that appear in response to a node "P" command have been re- arranged to appear in order at the beginning of the SET208.EXE utility as indicated: 1. Minimum Quality for Update 2. HDLC (Radio port) Channel Quality 3. RS-232 port Channel Quality 4. Obsolescence Count Initial Value 5. Obsolescence Minimum Count to be Broadcast 6. Nodes Broadcast Interval 7. FRACK 8. MAXFRAME 9. Link Maximum Tries 10. Digipeating 11. Validate Callsigns 12. Host Mode Connects 13. TxDelay 14. Broadcast via Port 15. Propagate # Nodes 16. Connect Commands PASSWORD STRING The Password string in version 2.08 requires a minimum of 5 and up to a maximum of 40 characters. These can be a combination of printable characters and spaces. SET208.EXE will automatically force spaces into that portion of the string that may be unused thus preventing previously loaded material from interfering with the new password. (This procedure is different than in version 2.06) NODE BROADCASTS As part of the network management process, there may be situations where propagating node broadcasts through either the HDLC radio or the RS-232 port may not be wanted. On a backbone trunked LAN system for instance, it might be decided no useful purpose is served by a LAN node sending out broadcasts on the LAN frequency (assuming no other radio nodes are on the channel). By turning off the broadcasts on port 0, an improvement in LAN throughput will be realized since a periodic source of unnecessary node transmissions has been eliminated. There also may be a situation where an occasional "propagation" node is on the LAN frequency. This node may be located at a point within the network where using the port 2 feature might not be appropriate. By turning off the port 0 broadcasts on both nodes, confusing routing paths will not be introduced into the system. Another way to ignore ALL incoming node broadcasts on the radio port would be to set Parameter 1 (Min quality for updates) to a value higher than the setting of Parameter 2 (HDLC channel quality). A possible application of shutting off the broadcasts from a LAN node to the backbone node might exist on a network with duplicate gateways. Here the network planners may desire that the traffic be routed through a specific gateway. In case the primary gateway failed, then the "backup gateway" could be SYSOPed into service. Users of this feature are cautioned once the broadcasts are halted on any port, nodes off that port will soon lose any memory of your node unless the N perming command is appropriately used. The SYSOP commands for this (parameter 14) feature are: 0 = Broadcasts disabled on all ports. 1 = Broadcasts enabled on port 0 (radio) only. 2 = Broadcasts enabled on port 1 (RS-232) only. 3 = Broadcasts enabled on both ports 0 and 1 (this is the normal, or default setting). HIDDEN NODES The "Node star" (N *) command is of primary interest to NodeOps that operate hidden nodes. As a matter of routine they use this command to make sure their # nodes are functioning. The majority of other users have little interest in the status of the hidden nodes. Even so, the hidden nodes propagate throughout the network the same as regular nodes. In this process they create additional (and oftentimes unnecessary) network overhead up and down the line. New with version 2.08 is a routine that prevents most (but not all) hidden node propagation. The exception to this are hidden nodes which are either permed or RS-232 (port 1) connected. This feature is found at Parameter 15. The SYSOP # Propagate commands are: 0 = Off (hidden nodes do NOT propagate; the normal or default setting). 1 = On (hidden nodes DO propagate). NodeOp usage of this feature will depend on the configuration of his nodes. The vast majority of NodeOps will find that the default setting will adequately allow him to check out his portion of the network without creating unneeded congestion for his neighbors. In addition, the default setting does not affect the propagation of the regular network nodes. Note: While permed or RS-232'd hidden nodes are broadcast by version 2.08, this only applies to those nodes that are DIRECTLY permed or RS-232'd. Another version 2.08 node downstream with Parameter 15 set to 0 will ignore the existence of these hidden neighbor nodes. CONNECT COMMAND In the quest for the perfect system, some networks employ the "Protected Backbone Trunking Concept". This is where only one transmitter per backbone frequency is allowed. The concept requires multiple backbone trunking frequencies on the system and is used in order to avoid "hidden transmitters" from slowing system throughput. Up to a five-fold improvement has been reported, even at 1200 baud. For a protected trunk to be successful, it is necessary to discourage users from directly accessing the backbone. High volume users typified by uplinking BBS or TCP activities are the ones of principle concern here. Ideally all users would agree and cooperate by not directly uplinking to the backbone trunk. In circumstances where this is not possible, version 2.08 is capable of managing the situation. One approach would be to use the Heard and Users features to determine if activity is taking place. If such activity is noted, then the L2/L3 callsign disallowance feature can be employed with specific offenders. NodeOps can alternatively use the node disable CONNECT command feature. A user uplinking or otherwise connecting to a protected node will be allowed the use of all node commands except the CONNECT command. Thus by not being able to connect FROM the node, such usage is discouraged and efficient network through- put is maintained. While throughput is enhanced by preventing users from directly UPLINKING to a protected (or, for that matter, any) backbone trunk, there is no penalty in allowing users to connect to protected nodes via the network. Indeed, for NodeOp diagnostic and out-of-area user mapping expeditions, it's desirable to normally allow user connects (through the network) to these nodes. It is therefore cautioned that the CONNECT disable be used as a last resort. Even then, perhaps only on an intermittent as needed basis. The SYSOP commands for this feature (Parameter 16) are: 0 = Off (Connects disallowed, user connect request will be quietly ignored) 1 = On (Connects allowed; the default setting) Another application where Parameter 16 would be useful is that of a dedicated point-to-point HF/VHF node-gateway circuit. Here, HF user activity can seriously degrade network throughput between the two node-gateways. By disallowing connects from the HF node, on-channel activity is discouraged and circuit throughput is greatly improved. (Network connects are unaffected as long as they are initiated from "CONNECT enabled" nodes.) Several NodeOps have reported difficulty with node initialization. Although addressed in the version 2.06 NodeOp manual, it bears mentioning again: If the new node fails to sign on, pull the TNC battery jumper for about 1 minute. This procedure neutralizes conflicting memory instructions remaining in the RAM from previous firmware. The new features found in version 2.08 have been requested by NodeOps. We hope you find these features useful as well. Our goal remains to make packet net- working as pleasurable as possible. We appreciate the comments and suggestions received to-date. Please address comments on the software to NJ7P and on the documentation to N7OO, both via packet @NJ7P.AZ.USA.NA. 73 de NJ7P and N7OO