                   --------------------------------------
--------------------------------------------------------------------------- 
          N.E.D.A.  - Devoted to Packet Neworking in the NorthEast 
--------------------------------------------------------------------------- 
                   --------------------------------------


                            G8BPQ PACKET SWITCH

                   --------------------------------------

                      Recommended CONFIGURATION FILE
                   Suggested BPQ Parameters equivalent to
                      regular NEDA Network Parameters.
                           for BPQ Version 4.08a

       (Revised Draft Copy from May 95 meeting for testing purposes) 
                               Rev:March 1996

                    Compiled and edited by: Burt VE2BMQ

     Only the parameters that should be adjusted from the values in 
     the supplied default BPQCFG.TXT are mentioned. You must still 
     enter all the parameters needed for your particular system in the 
     BPQCFG.TXT file. Consult the BPQ PORTS.DOC for required 
     parameters. Just try to make sure that the following parameters 
     are adjusted to the values shown.

Note: Any changes since the May 1995 meeting are detailed at the end of 
this document.
                             *****************
                         Network System Parameters

OBSINIT=5           INITIAL OBSOLESCENCE VALUE
OBSMIN=3            MINIMUM OBSOLESCENCE TO BROADCAST
NODESINTERVAL=15    NODES BROADCAST INTERVAL IN Minutes
IDINTERVAL=0        We don't need IDs.
L3TIMETOLIVE=13     MAX L3 HOPS.
L4RETRIES=2 (1)     LEVEL 4 RETRY COUNT - Does 1 actually work? 
L4TIMEOUT=180       LEVEL 4 TIMEOUT in seconds
L4DELAY=10          LEVEL 4 DELAYED ACK TIMER in seconds
L4WINDOW=2          DEFAULT LEVEL 4 WINDOW SIZE (L4 MAXFRAME) 
MAXNODES=100        Maximum known nodes in node table
MINQUAL=50          MINIMUM QUALITY TO ADD TO NODES TABLE. 
                     Note:this is not the same definition as the 
                     MINQUAL in the ports configuration section. 
                     Also it is overridden by QUALITY in the 
                     ports section.
BBSQUAL=128         BBS Quality relative to NODE - used to limit 
                     'spread' of the BBS through the network to 
                     your required service area. Start with 128 
                     and adjust so that BBS shows ONLY at the 
                     nodes normally used by its users. IE: At 
                     your stack and at the most one visible 
                     hop away.


                             TNC DEFAULT PARAMS

PACLEN=236          MAX PACKET SIZE in bytes.  More would
                     fragment NET/ROM frames.

                             LEVEL 2 PARAMETERS


T3=320              LINK VALIDATION TIMER in seconds (5 MINS) 
IDLETIME=7200       IDLE LINK SHUTDOWN TIMER in seconds (2 hrs) 


                           CONFIGURATION OPTIONS

HIDENODES=1         # Nodes only listed with N * command

                           **********************

                           AX25 PORT DEFINITIONS

                               User LAN Port
   * These parameters are for a visible port where live keyboard stations 
     access the network and access resources over the network. No station 
     is heard on-channel by the user port that transmits more than 3K/hour 
     average or 300K/Month. No node-to-node communications on this port. No 
     node broadcasts out on this port. All node broadcasts in on this port 
     are ignored.

     PORT
       ID=USER PORT
       QUALITY=0            Inhibits node broadcasts and L3/L4 connects 
                            on this port.
       MAXFRAME=1           for 1200 bps. =4 for 9600 bps (See note #9) 
       TXDELAY=350          Milliseconds
       SLOTTIME=200         Milliseconds
       PERSIST=64
       FRACK=6000           Milliseconds(See note #8)
       RESPTIME=500         Milliseconds
       RETRIES=10
       PACLEN=236
       DIGIFLAG=0
     ENDPORT

                           **********************

                            Non-Ideal User Port
* These parameters are for a visible port hearing other nodes, servers or 
any station generating large amounts of data. It probably would also be 
plagued by serious HTS (Hidden Transmitter Syndrome) effects. 
Affectionately known as a "ZOO" channel.

PORT
  ID=NON-IDEAL USER PORT
  QUALITY=0            Inhibits node broadcasts and L3/L4 connects 
                        on this port.
  MAXFRAME=1
  TXDELAY=350          Milliseconds
  SLOTTIME=200         Milliseconds
  PERSIST=64           Or even 40 for extremely congested channels. 
  FRACK=15000          Milliseconds.  This is the price you pay 
                        for a zoo channel.  Depends on TNC type. 
                       (See note#8)
  RESPTIME=500         Milliseconds
  RETRIES=10
  PACLEN=236
  DIGIFLAG=0
ENDPORT
                     *********************************

                                Gateway Port
* These parameters are for a visible non-2m port that acts as a hopping 
point between networks. Accepts node broadcasts from the other network but 
only broadcasts itself. The purpose of this is to allow two networks that 
have conflicting parameters to meet, allowing users and services to cross 
over, but without having the node lists intermingle. We're never going to 
get a gateway defined exactly because they will be customized for the 
various circumstances every time but this is the general idea. 

PORT
  ID=GATEWAY PORT
  QUALITY=50
  MAXFRAME=1           (See note #9)
  TXDELAY=xxx          Milliseconds - Set depending on Radio and 
                        parameters of the other networks that 
                        are gatewayed into.
  SLOTTIME=200         Milliseconds
  PERSIST=64
  FRACK=12000          Milliseconds- Adjust according to other 
                        stations on port.(See note#8)
  RESPTIME=500         Milliseconds
  RETRIES=10
  PACLEN=236
  DIGIFLAG=0
  MINQUAL=210          This effectively limits node broadcasts 
                        (on the port directed towards the other 
                        network) to this node information only. 
ENDPORT
                        ***************************

                             NETROM Matrix Port
* These port parameters are for a port connected to a NETROM/TheNET Node 
RS-232 port or to a diode matrix. It assumes that there will be no feedthru 
of Node information from any other ports on the BPQ switch. If there are 
nodes fed thru to be broadcast on this port, then Quality should be set to 
161 on both ends of the NETROM link (See note #7). Also make sure that this 
port is actually connected to a matrix or NETROM node (See note #11).

PORT
  ID=NETROM CONNECTION
  QUALITY=203          (See note #7)
  MAXFRAME=1           (See note #9)
  FRACK=1000           Milliseconds. Not important-few retries. 
  RESPTIME=0           Milliseconds (See note #10)
  RETRIES=10
  PACLEN=236
  FULLDUP=0/1          0 for diode matrix, 1 for connection to 
                        a single NETROM/TheNET node RS232 port. 
  DIGIFLAG=0
  QUALADJUST=100       (See note #1)
ENDPORT
                     *********************************

                           Direct BPQ Radio Ports
BPQ Ports with a direct radio connection are usually interfaced with a TNC 
operating in KISS mode or with an internal HDLC card like a DRSI card. The 
following are for KISS TNCs. Where other interfaces are used, use these 
parameters as guidelines.(See also: Shared KISS Ports (below)) 

                BPQKISS Dedicated Point-to-Point Link Ports 
* These port parameters are for a port used as a dedicated point-to-point 
link in a network using a TNC with BPQKISS EPROM installed or a Kantronics 
TNC with special KISS eprom. Use of standard KISS TNCs should be 
discouraged wherever possible.

PORT
  ID= DEDICATED POINT-TO-POINT PORT

  TYPE=ASYNC
  PROTOCOL=KISS
  CHANNEL=A            Or B,C,..according to how the BPQKISS 
                        EPROM was burnt.
  QUALITY=203 or 161    Use 203 if you are not broadcasting 
                        nodes from other ports.  Use 161 if you 
                        are broadcasting nodes from other ports. 
                        Node at other end of this link should 
                        also have HDLC quality set to the same 
                        quality as this port.(See note #7) 
  MAXFRAME=1           (See note #9)
  TXDELAY=xxx          Milliseconds - Set to value appropriate 
                        for the radio used.
  SLOTTIME=10          Milliseconds. See also: Shared KISS Parms 
  PERSIST=255          See also:Shared KISS Parms
  FRACK=4000           Milliseconds. (See note #8)See also:Shared KISS Parms
  RESPTIME=200         Milliseconds
  RETRIES=10
  PACLEN=236
  DIGIFLAG=0
  KISSOPTIONS=POLLED,CHECKSUM,ACKMODE
  VALIDCALLS=<callsign1,callsign2,...>   Used instead of locking ROUTES. 
                                          See note #6.
ENDPORT
                      *******************************

             Standard KISS Dedicated Point- to-Point Link Port 
* These port parameters are for a port used as a dedicated point-to-point 
link in a network using a TNC and standard KISS mode where it is not 
possible to use BPQKISS mentioned above. Standard KISS TNCs should only be 
used if it is impossible to use BPQKISS (or equivalent KISS using 
handshaking on the serial connection).

PORT
  ID= DEDICATED POINT-TO-POINT KISS PORT
  TYPE=ASYNC
  PROTOCOL=KISS
  QUALITY=203 or 161   (See note #7) Use 203 if you are not 
                        broadcasting nodes from other ports. Use 
                        161 if you are broadcasting nodes from 
                        other ports.  Node at other end of this 
                        link should also have RS-232 quality set 
                        to the same quality as this port.
  MAXFRAME=1           (See note #9)
  TXDELAY=xxx          Milliseconds - Set to value appropriate 
                        for the radio used.
  SLOTTIME=10          Milliseconds.  See also: Shared KISS Parms 
  PERSIST=255          See also: Shared KISS Parms
  FRACK=4000           Milliseconds.(See note #8)See also:Shared KISS Parms 
  RESPTIME=200         Milliseconds
  RETRIES=10
  PACLEN=236
  DIGIFLAG=0
  VALIDCALLS=<callsign1,callsign2,...>  Used instead of
                        locked ROUTES. See note#6.
ENDPORT
                     *********************************

                             Shared KISS Ports
* On the last two KISS port lists, if the port is used on a HTS (Hidden 
Transmitter Syndrome) Free SHARED channel, then the following parameters 
are to be used instead. A SHARED HTS Free channel would be one where more 
than two (2) stations, all of whom can hear each other well, are linked or 
where a regenerating digital repeater is used.

  FRACK=8000           Milliseconds (See note #8)
  PERSIST=xx           Adjust according to number of stations 
                        PERSIST=256/(N-1)
  SLOTTIME=200         Milliseconds
  QUALADJUST=100       Enables equivalent to X1J alternate 
                        broadcast algorithm. (See note #1). 
     ********************************************************** ****** 

                                   Notes:
                                
                                   QUALADJUST
  1. To enable the equivalent to the X1J "ALTERNATE BROADCAST ALGORITHM", 
     add QUALADJUST=100 (percent) to the Ax.25 port definition. This will 
     kill the quality of any node in the node broadcast from this port 
     whose best quality route also comes in on the same port. This has been 
     checked and verified. Use this feature on any port that sees more than 
     one network node such as a diode matrix connection or radio port on a 
     SHARED HTS Free channel including a channel with a regenerative 
     repeater.

                            Disabling Node Broadcasts
  2. To disable all node broadcasts from a BPQ port, set QUALITY=0 in ax.25 
     port definition. This will also prevent all L3/L4 connects on this 
     port. Use this parameter on all direct user ports.

                      Limit Node Broadcasts to Node Itself 
  3. To disable all node broadcasts except the BPQ switch itself from one 
     of its ports, set MINQUAL=210 (or any number higher than the highest 
     node quality in the node table but less than 255) in the ax.25 port 
     definition. This would be appropriate for Gateways. Do not confuse 
     this MINQUAL with the MINQUAL in the Network System Parameters section 
     of BPQCFG.TXT which defines the minimum quality to add to the node 
     table. This has been checked and it appears to be valid. Note: This 
     will NOT broadcast any BBS or other server application running on the 
     BPQ switch. This has also been verified.

                                UI Transmissions
  4. Where it is necessary to transmit UI frames on a radio port, such as 
     when a BBS sends TPK or "Mail For" beacons, the radio port must 
     operate directly from the BPQ. In these cases it is necessary to use 
     an internal HDLC card in the computer or a TNC operating in "DED Host 
     Mode" or in KISS mode. If you must use KISS mode, then use dedicated 
     BPQKISS firmware if possible. This is especially true for congested 
     radio channels where the "standard" KISS mode can seriously affect 
     throughput on the channel for all users. BPQ documentation says that 
     certain Kantronics TNCs using a special KISS EPROM are also equivalent 
     to BPQKISS. In a recent chat, a Kantronics representative said that 
     all Kantronics TNCs now had this special KISS as standard firmware. A 
     local JNOS user with a KPC-3 carried out tests that would appear to 
     confirm this. Can anyone else verify it?

     If you do not need to transmit UI frames on the radio port, we 
     recommend that the BPQ switch be connected to a diode matrix and all 
     radio ports operated as X1J nodes using regular TNCs. Even when you 
     have only one radio port, it should be connected as a TheNET node with 
     a "NETROM" cable linking the serial port and NETROM protocol used in 
     the BPQ switch. Then the BPQ becomes simply a multi-connection 
     interface for the BBS or other application. We recommend using a 
     BPQ/RS-232 timeout timer to prevent matrix lockups should the computer 
     crash.

                                Public Parameters
  5. It has long been NEDA policy that NEDA node parameters be open and 
     accessible to anyone for examination whenever possible. BPQ parameters 
     are normally totally hidden as an inaccessible file on the computer. 
     Putting the BPQCFG.TXT file in a public directory on an associated BBS 
     would meet this policy and would confirm that the BPQ switch was being 
     operated in a network compatable manner. The BPQCFG.TXT file should be 
     edited to remove John's explanatory notes so as to make it as short as 
     possible. A note in the INFOMSG could show the location of the file. 

                               Controlling Access
  6. Controlling access to the network ports of a BPQ switch is different 
     from a TheNET node. The VALIDCALLS parameter in the ax.25 port 
     definition section will limit those callsigns that can do L2 connects 
     to that port of the switch. It will not however distinguish between 
     SSIDs. It can also be used in much the same manner as the ACL function 
     of X1J but only for L2 connections.

     Locking ROUTES and setting default port quality to 0 (a common network 
     management practice with TheNET nodes) will not work with BPQ. Setting 
     QUALITY to 0 disables the node broadcasts from that port AND it 
     ignores all incoming node broadcasts. Setting QUALITY to a low 
     non-zero value like 1, even if it is lower than MINQUAL (in Network 
     System Parameters) still results in the neighbor nodes being entered 
     in the node list. This is not documented but comes from my own 
     observations. The only way to prevent connects from uncontrolled 
     stations is to use the VALIDCALLS parameter mentioned above. 

                             Port Quality Assignment
  7. The QUALITY assigned to a BPQ port on a node stack can be quite 
     confusing so let me explain the rationale. The NEDA policy of 
     assigning a quality=203 to backbone ports is designed to limit the 
     node propagation to a maximum of 7 TNC hops (usually equivalent to 
     three visible node hops). This policy effectively limits the size of 
     the node list to a manageable length of less than 100. 

     BPQ has different hardware than a dedicated hardware TNC node. One BPQ 
     switch (containing 1 CPU) will do the job of 2 TNC nodes (containing 2 
     CPUs) on each path through the node stack. The quality "decrement" 
     through 2 TNCs is equivalent to a quality of 161 (203/256 x 203/256 = 
     161/256). So to have the BPQ reflect the same parameters as a TNC node 
     stack the Quality would have to be set to 161. However this only 
     affects node listings that pass through the BPQ from one port to 
     another. A user port is usually configured with QUALITY=50 (and no 
     nodes broadcasts) so that it will not propagate nodes heard on that 
     port and so this quality argument does not affect it. Therefore in a 
     BPQ switch that does not pass any node information from one port to 
     another, QUALITY=203 is appropriate (since it is functionally 
     equivalent to one TNC). If node information is propagated from one 
     port to another, then use QUALITY=161.

     Another special case is a BPQ switch where all the ports are 
     interfaced to individual TheNET nodes. One purpose of such a "node 
     stack" would be to allow many more circuits (TheNET is generally 
     limited to 24) through a busy Hub node. In this special case, each 
     path contains three CPUs (one BPQ and two TNCs). We suggest that 
     QUALITY=228 on each end of all of the BPQ<>NETROM links would achieve 
     an overall quality = 161.

     Whatever the QUALITY assigned to a network port, the quality on the 
     node or BPQ port at each end of a network link should be the same. 
     This will avoid "non-symmetrical" routes which show further in one 
     direction than the other and may not be connectable from the extreme 
     ends.

                                 FRACK Settings
  8. FRACK parameter settings in a BPQ switch are a dilemma. It is very 
     dependant on the port configuration and even on the data rate. We have 
     to examine the conditions on the radio channel, the average number of 
     users at peak times, the mode in which the TNC is operated, etc. An 
     extreme example is the effect of using a regular KISS mode TNC on a 
     congested radio channel. The computer has no way of knowing when the 
     TNC has been able to transmit the frame so it must start the FRACK 
     timing immediately after sending the frame to the TNC. The FRACK must 
     be set to a value equal to the sum of the average time delay in 
     transmitting the frame plus the length of the frame (2 seconds at 1200 
     bps) plus the normal NEDA FRACK for a radio port of that type. This 
     could result in a value as much as 20 seconds and you can imagine how 
     that would slow up the throughput on a congested channel where 
     collisions are frequent.

     On the other extreme, a BPQ port feeding a NETROM node serial port or 
     a diode matrix, will not have any significant retries so the FRACK can 
     be set to 1 second. Other types of ports would naturally fall 
     somewhere in-between these extremes.

     Added on top of this dilemma is a lack of knowledge on just how the 
     computer handles FRACK. This will require a series of appropriate 
     experiments before we can choose the suitable values for FRACK under 
     differing conditions. We already know how it handles FRACK in a 
     regular KISS mode TNC. What we need to know is the operating mode for 
     the following:

       a/ TNCs operating BPQKISS with KISSOPTIONS=POLLED,CHECKSUM,ACKMODE. 
       b/ TNCs operating in DED HOST mode and G8BPQ HOST mode. 
       c/ Operation with internal HDLC cards like DRSI (may be 
          the same as /b ??).
       d/ Anything I forgot???

     Meanwhile until we can get results on some experiments, let's set 
     FRACK at 6 seconds (6000 milliseconds) on a quiet LAN user port and 
     dedicated links running KISS mode, 12 seconds on a busy LAN USER port 
     and 15 seconds on a "ZOO" channel. If you are running regular KISS 
     mode, please convert to BPQKISS which at least allows the computer to 
     monitor the outgoing transmit buffer. Better still if you can, convert 
     the TNC to a TheNET node and link the BPQ using NETROM protocol. (This 
     is not possible if running TPK or other UI frames on the radio port.) 
     The best situation would be to operate all ports in your facility as 
     TheNET nodes. Then use the BPQ switch linked to a diode matrix solely 
     as a multiconnect interface with an application like a BBS. 

                                    MAXFRAME
  9. There is a considerable controversy over the proper value of MAXFRAME 
     in a network. NEDA has from an early period recommended MAXFRAME=1. 
     Others say that this is ridiculous, that MAXFRAME=1 is inefficient and 
     slows throughput on links. Unfortunately neither side can back up 
     their positions with clear, logical and experimentally proved 
     evidence. Let's examine the positions.

     NEDA's policy is that all users have an equal opportunity to access 
     the available resources of the network. On a user port no- one should 
     have to wait a long time to get a frame transmitted or to receive a 
     frame from the node or server. This is achieved by setting L2 
     MAXFRAME=1 and setting appropriate persistence and slottime parameters 
     to allow opportunities for transmission to the node. At 1200 bps one 
     frame + TXD typically takes two seconds to send. Assuming say five 
     users on the channel, most of whom are receiving information from the 
     node or server, each user should not have to wait more than 10 seconds 
     per frame. If the MAXFRAME was set to 4 for example, some users might 
     have to wait as long as 30 seconds for their share. Not very fair. 
     Note: This MAXFRAME value only affects transmissions made by the node 
     or switch downlinking to the user. All uploaded frames are controlled 
     by the MAXFRAME parameter in the user's TNC.

     The opponents to the MAXFRAME=1 would say that may be fine for 1200 
     bps ports but for 9600 bps ports, the value should be higher. After 
     discussing it at the last meeting, I proposed that for higher speed 
     ports, higher MAXFRAME values were appropriate so long as any one 
     transmission to a user did not exceed say 2 seconds. MAXFRAME=4 or 
     even =6 on 9600 bps user ports would meet this criteria. MAXFRAME=3 
     would be appropriate on a 4800 bps port.

     MAXFRAME settings on the backbone links are another matter. NEDA has 
     again held that MAXFRAME=1 insures equal sharing of network resources 
     and has results of early experiments that supports the claim that the 
     overall throughput of the network is higher at MAXFRAME=1. Opponents 
     counter that this is the result of a large number of slow 1200 bps 
     links in our network and if we were to install all high speed links, 
     the NEDA claims would be proven wrong. At this point however, there is 
     no solid experimental evidence to prove either way. There is great 
     need to research this important matter. Meanwhile we continue to 
     recommend MAXFRAME=1 because we know it works and has no serious 
     detrimental effects on the network (like totally locking up). 

     It is my opinion that one of the most important factors in overall 
     network performance of TheNET networks is how "chokes" are handled and 
     the effect of chokes on network data flow. It was my impression (on 
     reading the original NETROM documentation) that if a NETROM L4 link 
     chokes due to one circuit being unable to deliver its data, then all 
     the circuits being handled on that L4 link are also stopped although 
     they may well have clear destinations that are not affected by the 
     choke. However, as a result of a recent "accidental" experiment, this 
     was proven not to be true, at least not for TheNET and NOS systems 
     (the "experiment" involved a circuit through more than 20 TheNET nodes 
     - both X1J and 2.0x types - ending in a JNOS converse node system). 
     Even though that one circuit was totally choked, other streams moved 
     through parts of the same path without hindrance. A similar experiment 
     involving a BPQ switch has yet to be run.
                               ******************

                  Changes and added notes since may 95 meeting. 

                          Response Time on NETROM Port
 10. It has been noted that the response time is also active when linked to 
     a NET/ROM diode matrix. This is different from the serial port of a 
     NET/ROM:TheNET node where response time is ignored. A significant 
     response time on a BPQ port feeding a diode matrix has the effect of 
     greatly slowing communications on that port. Set RESPTIME=0 to 
     eliminate this slowing effect. Setting RESPTIME=0 does not seem to 
     have any detrimental effect but if you would feel better with non-zero 
     value such as 1 (millisecond), then do it.

                            Unconnected NETROM Ports
 11. Unused ports, especially NETROM configured ports, should be commented 
     out or at least make sure the pull-up resistor is in place on the 
     serial connector. Several installations have had problems with the 
     switch locking up for no aparent reason. When the unused ports were 
     commented out, the lockups stopped. (Credit: W6GO report) 

               *************************************************** 
                                 Call to Action
     If you guys have any better ideas, let's hear them. Meanwhile all of 
     us that run BPQ can check out these above-mentioned parameters for 
     serious problems.
                             ***********************