Monitoring Connections

It is important to understand the difference between a connectionless and a connection-oriented networking protocol before we go further. Most networking protocols in regular use today, with the exception of ATM, DTM, frame relay, and the various optical networking protocols, are connectionless. Each frame that gets transmitted over the wire or fiber contains all the information it needs to identify who sent the frame, and where the frame is going to. Sometimes it's routable, as the case is ROSE-addressed AX.25 frames. Sometimes it's not, as is the case with Ethernet frames. Anyone sniffing the network need not remember anything about the packet once it has been processed; it is completely stateless and self-describing, as will the next one be.

Connection-oriented networking protocols are quite different: they choose to negotiate routing and connection information up-front in a procedure called "call establishment." Once that's taken care of, all future network frames only reference the connection that data is flowing through. This offers considerable savings in network header overhead, a critical factor when your network channel is heavily loaded, as it allows you to maximize usable data bandwidth. Commercial Frame Relay (itself an evolution of X.25) is an example of this kind of network.

AX.25 just happens to be both at the same time and at will. While some applications benefit significantly from AX.25's connected-mode operation, it also offers explicit support for connectionless operation as well, a great benefit for passing routable layer-3 protocols like IP. This makes AX.25 quite unique in the taxonomy of protocols in the world, easily making it one of the most powerful protocols ever invented. This is quite likely the reason for its long life after all these years!

In AX.25 V2.0 and earlier, the structure of the frames relayed in a connection just so happened to be consistent with the frames that were relayed in a connectionless manner. This made network monitoring quite easy, since no special case decisions needed to be made, and each frame could be examined in isolation to determine precisely what was going on.

V2.2 of the protocol, however, has taken advantage of its connection-oriented support to allow a clear distinction between modulo-8 and modulo-128 data flows on the same channel. This creates some interesting problems for network monitors. Since the decision to use modulo-8 or modulo-128 is made at connection-time, and not during the flow, it follows that the network monitor must now track connections. Monitors must now maintain connection state.

Modulo-8 connections use an 8-bit control field, are established when the client node issues a SABM frame to the server node, and is accepted. Modulo-128 connections, which use a 16-bit control field, are established when a SABME frame is issued instead.

If a monitor misses the connection establishment handshake, it can then rely on packet lengths of U- and S-frames to intelligently guess the correct size fo the control field. However, if I-frames are passed, a heuristic will be needed to properly identify the size of the control field. If the PID field changes with each passing I-frame, for example, it's likely being used as the N(R) field. Alternatively, one can look for PIDs that aren't likely to appear on the channel. If you know that the connection is passing IP traffic, for example, you can attempt to correlate the IP header at two locations in the frame and verify that the CRC field matches at only one location. That will also lend strong credibility to the size of the control field. Of course, only by comparing the length of a received U- or S-frame will the monitor know conclusively.

Although the network monitor will now need to maintain state about a connection (this is probably a good idea anyway, since you can then gather statistics about the traffic on the channel), the issue of memory consumption arises. Fortunately, few AX.25 LANs are expected to grow to have significant numbers of stations on them. CSMA(-derived) channel access policies are just too expensive, especially for the slower link speeds. It is reasonable to limit a monitor's memory requirements to just 200 or so nodes for current networks. With each callsign pair taking 14 bytes or so of memory, and assuming close to 16 bytes for other maintained statistics, it follows that complete state and statistics for all connections can be maintained in less than 8KB of memory. This is quite doable even on most small home computers, such as a Commodore 64, and therefore should not pose any kind of problems from a practical stand-point.

Parameter Negotiation Timing

One bit of confusion with respect to the AX.25 protocol is that you can exchange XID frames with any node on the network at any time, safely. Because XID frames only reports, never modifies, preferences of a node, it is entirely possible to do this as XID exchanges are completely idempotent. It is the responsibility of the nodes sending UI- or I-frames to never exceed the destination's PDU size limits or other resources.

The basic idea is for a node to send a XID frame saying something like, "I support modulo-128 frames and a frame PDU size up to 8KB." Then the node receives a response XID, that says, "I support modulo-128 frames and a frame PDU size of up to 4KB." The sending node now has enough information to (a) know that SABME can be sent without expecting a FRMR response, and (b) knows that it must restrict its PDU sizes to that destination to only 4KB. Through this process, an IP stack may perform MTU discovery, for example, without the aide of a human operator.

What needs clarification is that, in order to support this aspect, nodes must not change their attributes mid-stream. If software is upgraded on a live site that allows the node to accept 6KB PDUs, for example, these changes are reported in a XID frame only for new connections. Old connections that are still in progress must report their old values.

If XID frames are not exchanged, then it is assumed that both parties are capable of supporting at most 256 octet PDUs.

Detecting a Failure To Connect

There are two ways for a connection attempt to fail. First, the node you're connecting to can simply not exist on the local network segment. In this case, your station will transmit SABM(E) frames periodically until it just gives up. In this case, after sending an SABM(E) frame, the counter is started, and when it expires, the frame counter is incremented. If the counter exceeds some reasonable (usually configurable) value, it is assumed that the other node doesn't exist and/or isn't accepting connections from you. Obviously, if you get a UA-frame acknowledging the connection request before a timer expires, the connection is established.

Another possibility is that the node does exist, and just refuses to talk to you. In this case, the node issues a DM U-frame in response to the connection request. This offers immediate confirmation that your connection has been refused.

Link Multiplexer

Wagner writes, "I was sure that the link multiplexer would be used to manage the distribution of outgoing packets to various ports." [1] This assessment is correct to a limited extent: as defined in the AX.25 V2.2 specification, it exists within layer 2. However, multiplexing is the wrong word to use to describe the tossing of frames around to various output queues. The real word should be switch. While the Link Multiplexer does perform some aspect of switching, its primary job is quite different. The choice of words used in the specification has lead to some amount of confusion.

The Link Multiplexer, as defined in [2], is responsible for plucking packets out of various queues and scheduling them for output over a specific port. It should probably be renamed the Link Switch, because within the component are multiple instances of true multiplexers. See figure 1. Each data channel queue represents a single abstract flow of data: e.g., between KC5TJA-0 and KC5TJA-2, for example. The server software generally doesn't know nor should care which port this occurs on. For example, in the figure, KC5TJA-1 and KC5TJA-2 both appear on the same physical port, while KC5TJA-3 appears on another port.

Part of the job of the Link Multiplexer is also to schedule out-bound frames as well. The concept of scheduling flows of data isn't addressed in the standard, except to say that some frames are sent with "expidited priority" or "at the earliest possible opportunity." Since the individual physical layer sees only a simple, flat, first-in-first-out queue, it follows that it is the responsibility of the link manager to properly dispatch higher priority frames before lower priority frames. See figure 2 for one possible implementation of this concept. In this scenario, the management data link is able to deposit frames in either the high or normal priority subqueues of a data channel. Normal I-frame traffic gets deposited only in the normal priority subqueue. When it's time to schedule packets for transmission again, the link manager first scans and places traffic from all the high priority subqueues before placing frames from the normal priority subqueue.

This concept of scheduling, in fact, can be generalized to support things like traffic shaping and flow priorities too. For example, especially on a 1200bps link, interactive sessions should always take higher priority than bulk data transfers in the background. The AX.25 specification doesn't address how to achieve this (nor should it, to be honest). Nonetheless, it is the Link Manager where you'd implement this kind of feature.

Digipeater Addressing

Nothing has raised more controversy with the AX.25 V2.2 standard than the issue of digipeater addressing. I have my own opinions about this, but I'll defer them for another article. For now, remember it is a stated goal that AX.25 V2.2 be backward compatible with V2.0, which means it must support a total of 8 addresses in the address field. Regardless of what the current specification states, it must be prepared to receive them, and it must be prepared to generate them if need be.

It appears that the authors of the V2.2 specification intended the digipeater address fields to be used only to support ROSE operation, and even then only as a concession. All other methods of extending the range of a packet contact were to be performed either through NET/ROM, or through the use of layer-3 routable protocols, such as IP. While it does modernize the AX.25 specification in a sense, it also is quite ambiguous about how frames with digipeater addresses are to be handled.

It is my belief that this section of the V2.2 specification should be ignored, and revert back to V2.0 semantics, with the proviso and understanding that digipeaters are deprecated. It doesn't affect the remainder of the V2.2 specification to do so, and guarantees 100% backward compatibility with earlier generations of the protocol.

KISS is a Layer 2 Protocol

The author of [1] expressed some amount of concern regarding how to properly handle KISS. This discussion applies equally well to 6PACK as well as to SMACK as well. Nothing that follows is KISS-specific.

It was stated in [1] that KISS was apparently below the layer-2 level, since AX.25 sat on top of it. A reasonable argument, but one which fails a few simple tests. Layer 2 protocols may encapsulate other layer 2 protocols as well as any higher-layer protocol as well. ATM does this to encapsulate Ethernet frames in its LANE environment, for example.

The first test is: does the KISS standard define any tangible items which can be measured with the aide of measuring equipment? For example, voltage levels, time durations, etc. The only thing that can be measured with KISS is the length of a frame, but even then, no hard limits are specified. Secondly, does KISS define the semantics of individual bits and the propegation of bits to another location? Again, the answer is no. Therefore, KISS is not a layer 1 specification.

KISS does fulfill the requirements of a layer-2 specification, however. It describes the framing used to delineate messages on a link. It describes a means of addressing so that multiple devices can exist on a single link. It also describes some simple parameter negotiation as well.

Finally, although KISS lacks a protocol ID field, KISS encapsulates other protocols. It is entirely possible to wrap IP with KISS frames, or AppleTalk, or IPX. The only prerequisite is that the peer node know a priori which higher layer protocol is being used (since KISS lacks a PID field). In fact, those familiar with both KISS and SLIP will immediately recognize that KISS is a variation of SLIP.

Because KISS lacks any kind of connection management, however, it follows that KISS is a purely connectionless protocol. Therefore, there is no inherent way to manage the loss of data frames, nor is there a way to throttle traffic flow. If you send a KISS frame to a device faster than it can process them, it will drop the KISS frame like a hot potato. A higher layer protocol is expected to be used to implement link reliability, if it's even desired, which to date, it hasn't been.

KISS is most often used to tunnel AX.25 frames over their native port framing. They provide the illusion that the AX.25 stack is talking to a native AX.25 network interface, just as TCP gives the illusion of a true, connection-oriented network on top of a connectionless (IP) underpinning.

This implies that if one wanted to, you could use AX.25 over KISS as a lower overhead alternative to TCP/IP/PPP for communicating over a serial or parallel port link between multiple computers.

Managing Traffic Rates with KISS Devices

Another concern raised in [1] is how to manage traffic flow to a KISS device, so as to not overflow its buffers. This is a more sticky problem than one might realize, because the TNC may not ever transmit any frames (consider a link that has a broken transmitter, where the carrier is always on).

The documented philosophy is analogous to the Ethernet cure-all for bandwidth management: Memory Is Cheap. However, I personally feel this answer is not acceptable as a general solution. It works now only because AX.25 traffic is so low in volume. As data link rates increase, however, it is conceivable that more users will start to use packet radio as a viable mode. If multi-megabit per second service becomes commonplace for packet radio, the need for modulo-128 frames with large PDUs increases substantially, and that means KISS TNCs with potentially megabytes of memory to hold all the frames needed from all the different sources. This, to me, is unacceptable.

There are three approaches towards flow rate management. Implicit Congestion Hypothesis, such as what TCP uses to "back off" transmission rate until it gets positive affirmation of a successful data transfer, Explicit Congestion Notification (ECN), such as that used on commercial Frame Relay circuits, and Explicit Rate Notification (ERN), such as that used on ATM circuits in the ABR traffic class.

While implicit congestion control requires the least amount of bandwidth possible, it offers sub-optimal performance, and takes a long time to recover from any kind of packet loss (thus potentially wasting otherwise usable bandwidth). Current research appears to be spending the majority of its time with ECN and ERN techniques. Note that none of these approaches are mutually exclusive!

AX.25's connected-mode operation supports a primitive form of ECN. When you connect to another station via AX.25, RR and RNR frames are passed to perform both acknowledgement as well as to throttle the flow of traffic. (Footnote: I'd be very interested in seeing some academic papers comparing X.25's RR/RNR approach towards Frame Relay's ECN or ATM's ABR ERN approaches. Please e-mail me if you have any links, as I've not found any yet myself.)

ABR-class traffic in ATM circuits and IPv6 both have options to use ERN for congestion control, where the end-points, and ideally all intervening switches, cooperate to assess how fast you can transmit data without causing packet loss or congestion. This guarantees minimal buffer loading by deliberately throttling traffic at the end-points so that the core infrastructure doesn't get overwhelmed. It's generally considered a much better idea to implement ERN as low in the network stack as possible. Although AX.25 lacks explicit support for ERN, it is still possible to implement by declaring a new layer-3 protocol ID dedicated to such "resource management" traffic. This should be a topic for future research.

With this background in mind, it is easy to see that if we already strip the knowledge of AX.25 out of the KISS TNC interface, what we end up with is a plain-vanilla modem with unpredictable behavior. But what if we re-insert some amount of AX.25 protocol knowledge into the TNC, just enough to allow efficient rate management via RR and RNR messages? Or, to detect and employ ERN resource management traffic? The result is an AX.25 switch, that happens to have two ports in its most common configuration. This is a significant development because it easily permits independent management of data flow between the host and the TNC, and between the TNC and the network at large. The number of ports can also be increased, thus also allowing multiple computers to access the same RF interface concurrently.

Conclusion

I have provided what I believe to be additional clarifications to the most recent AX.25 specification, which I believe to be true to the intended protocol, yet easier to understand for those not familiar with reading complex specifications. Additionally, I have prescribed what I feel is a more rational approach towards handling digipeater addresses. Finally, ideas were put forth for managing local network congestion based either on raising the intelligence of the network interface somewhat to allow for proper AX.25 congestion management, or to rely on explicit rate notification traffic to afford a more complete, end-to-end congestion management solution.

Works Cited

Acknowledgements

Thanks go out to Jim Wagner (KA7EHK) for reviewing this article, as it contains mostly responses to his questions. Hopefully I didn't confuse him further!