...connecting the future...
A contemplation, that the software-author represents in the following article, over the Routing, describes for each Sysop, which is important for a well working node and is to be believed which peculiarities with the Parameters of the Digis, descriptive and plastic. Jimy, DL1GJI, explains on this occasion also peculiarities his XNet-Software regarding the improved Routings.
Stage, Link: secured point to point connection of the layer 2. Bows, Loops: originating through inconsistencies in the Routing table.
By Routing, one understands the search after a way of nodes A and nodes B within a network. If there are several ways, the best interests us. What is the best?
In the amateur-radio, there are two essential criteria after which we can compare two ways together:
How long does an answer of the counter-station take to get to me?
How many bits per second can I transfer on this path?
With the FlexNet - and NetROM-Routing, these two specifications are different, i.e., one assumes that good throughput means also a good answer-time. FlexNet assesses the different ways with theoretical terms (from 0 to 500s). In the event of multiple paths to a node, the selected path is calculated with the shortest total-term. NetROM-Routers assess the ways with a so-called quality (from 0 to 255). This total-quality is also calculated from the qualities of the stages (hops), and is somewhat complicated. The path is chosen with the highest total-quality. The FlexNet-run times are descriptive also for the users while the NetROM qualities represent a rather abstract code. The Router only uses these numbers for itself for point to point however let’s suppose there are 3 possible paths to a node, according to the minimum transfer time route or maximum quality route, is the NetROM quality the only selection sufficient to achieve the best path? If it is decided that a Flexnet route would be best then that is the chosen method.
The topic Routing is so interesting in the Packet-Network because RF is subject to permanent fluctuations. Links used at their maximum run well once, bad once, or they are cancelled completely. Sometimes nodes are turned off new nodes arrive etc. Because nobody finds the time and the desire to configure the network again, the routing must take place automatically. Also the data information must exist for routing, i.e., the terms or the qualities of the stages automatically are determined. FlexNet and TheNetNodes use specifically defined "Round-Trip-Time" in each case, RTT-Packet about the term or the quality of a stage permanently too presumptuous. The basis is created with both methods to choose the optimal path amongst the best routes.
With NetROM, a path must be confirmed to a node again and again (Nodes Broadcasts). Otherwise, NetROM forgets the way after an hour. Only the stable ways are permanently entered in by the direct neighbors and remain. This forgetting of a path after an hour is also only possible with TheNetNode and still today needs to receive a node from the network again. However, through "reverberation-effects", dropping a path can last up to ten hours until a relaxed node vanishes completely from the network. Through a meaningful expenses-waiter-border, one can moderate this cosmetic characteristic:
Which nodes should they take into account with the Routing at all? Always, worldwide, how are all nodes in the destination or Nodes-List represented? If the pure Connect already lasts 10 minutes, the existence of this node is no longer interesting. Therefore, there is an expenses-border in the network, the node-information is relayed. With FlexNet, this border is the total-term of 500 milliseconds. With TNN, it is the minimum-quality (MinQuality) parameter. This expenses-border has however also another important function: because in the network if a node vanishes, this node should immediately be purged from the node-list…Theoretically yes. That is not practical so: one sees that the node remains in the network, merely the quality sinks or the term ascends. Overstep the expenses-border the node, it finally becomes invisible. It formulates differently: give it no expenses-waiter-border, zombie-nodes would create a network with craziness-terms or mini-qualities in the Routing-Table to have large numbers.
The principle of the "divided horizon" means that one returns the node-information, that one doesn't get from the one part-network, into this part of the network but relays information to the other networks. One always transports the Routing-Information direct to the front. With network-topologies inheriting this principle is enough to hold crisp information freely about the Routing. The amateur-radio-network has become extremely strong. Sharpen-freedom is not to be reached with this principle alone. Negative feedback is to be solved a method about the problem better.
The principle of the "negatives feedback" goes like "Split Horizon" from similar considerations. While directed Split Horizon "the Routing information only goes to the front", Poison lapels "send back" the information as well but negatively. In NetROM the front the positive Qualities are reported, in backward directional, the Quality is sent as 0.
The idea is clear, the faster the Routing-Information is relayed, the more quickly the network responds. Alterations in the Routing-Table should be relayed as quickly as possible, however the next problem immediately originates if one makes use of this method too often creating Broadcast Storming.
Does the Router transmit information too often and too quickly with updated data? Then it can be said that "Broadcast Storms happen. If an important stage is cancelled in the network, all nodes only devote time to the passing of updated routes for seconds. There must be borders for these updating. A possibility is that updating can take place in a minute second at best.
The following describes the like from the above general concept in the node-software of XNet. The compatibility of other protocols to existing NetROM remains 100%.
XNet guarantees that the quality of a node sinks per stage about at least 5 points. The normal quality-calculation, which sinks the quality again, is also made. If for example we put MinQual on 100 everywhere, one can guarantee that the node is not spread further than 31 hop, 5 * 31 = 155. If a node is cancelled, the energy is withdrawn from the "reverberation-effect" and the node vanishes more quickly under the MinQuality.
This principle can be reached ideally with the existing NetROM-Protocol. However not with the station transmitting, as above described but with the receiving station.
Example: that XNet Digi DB0SIG gets the following NetROM-Routing Broadcast from the neighbor HB9AK:
= >monitor -u +4 4:fm HB9AK to DB0SIGS via DB0BAX * ctl UI ^ pid CF BC SARTG :HB9AK signature: FF  GOE :DB0GOE via DB0EAM 199 GS :DB0GSH via DB0SIG 178
DB0SIG recognizes that HB9AK the node DB0GSH over DB0SIG route. DB0SIG now puts the Quality of DB0GSH in the reverse conclusion over HB9AK on 0:
= >r d DB0GOE HB9AK 199 DB0GSH DB0LBG-7 200 DB0GSH HB9AK 0
Every 10 minutes XNet performs a Broadcast of the entire Routing table. Alterations of the Qualities submitted to the network in the meantime that bigger than the set MinQual are added. If nodes are not reached or suddenly become bad, qualities will have plausibility-examinations (DL1GJI) in the event-controlled Broadcast is distributed the NetROM-Broadcasts to all nodes in the same form in principle. Smart routing also is incorporated. If node A broadcasts that it hears node B with a higher quality than how XNET hears node B in a direct path, XNet reacts in that the right quality of node B it sends out with help of the event-controlled updating and removes the Quality size with it. At the moment, these information is simply discarded with the TNN - however exactly with this Plausi-Check has recognized itself with the NetROM-Protocol tie. This case becomes in the on-line-protocol from XNet the Sysop as follows told:
= >log Log-Messages Router: Quality of DB0EAM (220) from HB9AK via me (219) too high
XNet works with a Routing table sorted after Call, that essentially contains the Call of the nodes and a referral at the current best Link. In order to refer an L3-Packet, only a binary search is necessary to log N with it after the Time-Call, in order to determine on the Link how the packets trip continues. TNN clatters the complete Nodes-List through n/2 to this in each case.
At the moment, it looks with TNN so: the Link quality is measured by the L3RTT. This result is written down into the Routing table. Problem: if the Link now subsides, we have the wrong information for 5 to 10 minutes. If the Link becomes so bad, that also the Broadcasts are no longer transferred, this wrong-piece of information lasts up to an hour (Route-Timeout-time). With XNet: the Link quality is measured by the L3RTT. The Broadcasts received, but in the original ways stored, as well as, updated. Every 20 seconds in the background, a new Routing-Table from the Link qualities and the present Broadcasts are calculated are stored. Lose a Link now; all nodes that emerge over the path of this Link have their qualities dropped to 0 immediately, and it drops routing for nodes over this Link. If they are found over alternative routes then the best route is chosen or if no routes are available, they fall from the Routing-Table. In the event the Link is restored, the same can take place in the other direction: the Quality of the Nodes increases itself again and routing is as was. Its not necessary for the reception of a new Broadcast to change it, because the old Broadcast is possibly still there, up to 1h in memory.
Producing of the Routing table takes place through a background-process as to not halt the Digi during the updating of the Routing table. XNet works with two tables: the actual Routing table and a shadow-table for the new evaluation. The tables are exchanged after a new evaluation has taken place, in each case, 2 pointers. The execution of processes and the updating of the Routing-Table happen in parallel consequently.
In that one compares the node-qualities in the old and the new table, one can determine differences and gets updated with the list of the nodes that have event-controlled, Triggered Updates without halting other processes within the Digi making the operation transparent.
The individual layers in each case or several processes is allotted. The synchronization of the processes takes place through semaphores and through coordination-counters. High priority processes, like for example the HDLC-Process of the die time control are running continuously without being stopped, all other Processes will be activated ("triggered") by request and stopped again when finished. The statement "process switch" in XNet statistics means like often the HDLC-Process will immediately go through. This statement is comparable with the "Rounds per Second" in the TNN.
Value Now min Max process switch [hz] | 6033 | 2675 | 6235 | - |
The statement / Timer accuracy "
timer accuracy | 60000 | 60000 | 60015 | - |
state exactly how the internal Software-Timers work. In the above case, the maximum postponement amounted to 15 ms in 7 working-days. In the DOS-versions from XNet often sees essentially higher values that originate through hard disk-access.
The "Round Trip" measurements from the KA9Q-kernel is implemented in most Packet-Programs today. With the newer implementations, as XNet, is viewed not only the average-value but also the scatter of the values around the average. The estimated value for strongly fluctuated RTTs is essentially higher than the estimated value for virtually constant RTTs. This procedure fits itself in the practice essentially better the realities on the QRG at.
Exactly in the case where the Routing is not correct one time and bows come into existence, high values of the L3RTT-Lifetime of too incredibly high network worries begin if the packets with maximum speed rotate through several nodes in the circle through. The standard-value of 30 hop is already very high. XNet calculates the Lifetime from the simple formula
lifetime = min(l3lifetimeparameter(280 – Node quality)/5,
become in the most decrease with a Lifetime < 30 connects.
= >r n 3NETNF DL1GWX-7S 6 1616 CHARLY DL1GWX-11 6 3612 Lille F8KOT 3 50000 <= default RTT ZHGATE HB9AB-10 5 3560 SARTG HB9AK 5 6096 TITLIS HB9AK-14 5 3255
BITRATE =, TWINDOW * PACLEN * 8, / TACK = (10 * 236 * 8)/4 = 4720 Bit/sec
Jimy shearers, DL1GJI ,
Peter Stirnimann, HB9PAE,: