OpenAX.25 - Link Manager
Overview
The Link Manager (LM) is the central core of OpenAX.25. It is responsible for routing network traffic to the intended recipient(s). As a result, literally everything else that (in)directly uses OpenAX.25 will utilize the LM's services.
Background
X.25 is often cited as the quintessential packet structure that violates the OSI layering methodology so badly that, in the eyes of many, it's not possible to build properly factored network implementations using the protocol. AX.25 is a descendent of X.25 by lineage, and it follows naturally that these perceptions hold true for AX.25 as well. Below is a typical AX.25 I-frame packet structure.
| Flag | Dst addr | Src addr | Control | PID | . . . PDU . . . | CRC | Flag |
What truely violates the layering principles defined by OSI is, really, the fact that the Control byte comes before the PID field, not after. Placing it there inextricably puts higher-level functionality, such as reliable packet delivery, at layer 2 instead of at layer 3, where many feel it belongs.
To restore the ability to process AX.25 frames in a properly layered manner, a mechanism is required for "skipping over" some bytes of the header, while still communicating them to higher layer software. The method must be as fast as possible to ensure high network throughputs, and must be fully backward compatible with future AX.25 protocol specifications.
Design
Historical evidence suggests that the process of applying an AND mask and, optionally, a XOR mask to data is useful for classification purposes. Indeed, the Internet protocol is engineered explicitly to be routable using only AND-masks, making hardware implementations very efficient.
The link manager utilizes this approach to properly route packets as they arrive. When a packet arrives, the link manager applies the packet to a set of AND/XOR filters, starting with the longest defined filter, and working its way to progressively shorter filters. A copy of the packet is forwarded to all processes that have matching filters. If a client application has several filters defined, it is possible for a packet to be forwarded more than once to the same client. Clients are assumed to be able to handle this condition on their own.
If we treat a received frame as a simple integer that is N*8 bits long, where N is the packet length, then we can define a match as the successful application of an AND mask of similar length, followed next by the XOR mask of similar length, to yield an integer of similar length equal to zero. This reads pretty difficult, so please look at the following figure.
| Phase | offset +0 | +1 | +2 | +3 | +4 | +5 |
|---|---|---|---|---|---|---|
| Packet data as received | $4B | $43 | $35 | $54 | $4A | $41 |
| AND-mask | $FF | $FF | $FF | $00 | $00 | $00 |
| ANDed result | $4B | $43 | $35 | $00 | $00 | $00 |
| XOR-mask | $4B | $43 | $35 | $00 | $00 | $00 |
| XORed result | $00 | $00 | $00 | $00 | $00 | $00 |
In this example, we have six bytes that comprise the callsign field of a packet. We want to check if the callsign starts with "KC5", but we don't care about the rest (e.g., match all callsigns starting with KC5). First we apply the AND mask, to yield a six-byte intermediate result. Next, we apply the XOR mask, which produces zeros only on a perfect match.
If we attempt to match KC6TJA against the above filter, we get the following result:
| Phase | offset +0 | +1 | +2 | +3 | +4 | +5 |
|---|---|---|---|---|---|---|
| Packet data as received | $4B | $43 | $36 | $54 | $4A | $41 |
| AND-mask | $FF | $FF | $FF | $00 | $00 | $00 |
| ANDed result | $4B | $43 | $36 | $00 | $00 | $00 |
| XOR-mask | $4B | $43 | $35 | $00 | $00 | $00 |
| XORed result | $00 | $00 | $03 | $00 | $00 | $00 |
As you can see, the resulting integer is not zero; therefore, no match occurs. The LM extends this concept to the entirety of the AX.25 frame, thus allowing applications to even match against patterns inside the PDU field if desired. This is useful if you don't care about the AX.25 header itself (e.g., you're using AX.25 over a point to point link, where addresses of each node are known a priori), but where the frames are carrying routable traffic within the AX.25 PDU, such as TCP/IP.
If a received frame is shorter than a filter, then it obviously doesn't match, and is therefore skipped.
If a filter is shorter than a received frame, the unspecified bytes of both the AND and XOR mask are implicitly taken to be $00. This allows client applications to only specify the shortest frame prefix that makes sense. It also makes for faster filter comparisons as well.
Associated with all packets is a port ID, which is logically prefixed to each received frame. Although physical ports are obvious mechanisms by which a packet can be transmitted or received, client applications are themselves treated as virtual ports. This permits additional post-processing of a frame once "transmitted" or routed. For example, an application may employ DSP to modulate the packet via OFDM or wavelet modulation for higher throughput transmission over conventional channels, without the LM having to be the wiser of what's going on.
Port IDs are assigned dynamically; hence it is never possible for an application (which may be a physical port driver) to know in advance what its port IDs are going to be. Neither, therefore, is it possible for an application to know, in advance, what port to send frames out through. Applications may query the LM to resolve a symbolic port name to a port ID. Likewise, when connecting to the LM, an application may bind a public name to the port thus created.