HDLC has been incredibly successful in providing transparent data communications on a multitude of data channels of all kinds, ranging from copper, to fiber, to radio, and presumably acoustic wave as well (e.g., inter-submarine communications). AFR takes the general capabilities of HDLC and generalizes it into an abstract interface. As long as the layer 1 implementation can provide an HDLC-like level of service, AFR can use it for a transport.
The following assumptions are placed on the layer 1/layer 2 boundary interface, as seen from the layer 2 perspective:
| SYNC | L2PID | payload data unit (L2-PDU) | SYNC |
The AFR implementation will make use of the native OSI Layer 1 facility for generating a unique symbol that clearly delineates different frames. This ensures that the symbol never appears anywhere within the frame.
The L2PID (Layer 2 Protocol ID Field) is an octet-wide field identifying the precise format of the data contained within the L2-PDU field. Currently, L2PIDs should defined starting at 0xFF and counting down. This allows software employing KISS modems to instantly auto-detect AX.25 frames from AFR frames, simply by checking bit 7 of the L2PID field.
This is a general purpose data field, within which is encapsulated another layer 2 protocol. For example, this could be an MPLS-tagged IPv4 frame, an encapsulated AX.25 frame, an ATM-CIF frame conveying ATM traffic, MA/CAPS transactions, telemetry such as a header-reduced form of APRS, etc.
Note that OSI Layer 2 is required to establish point-to-point or point-to-multipoint communications. Since the outermost AFR frame lacks source and/or destination fields, or virtual channel fields, the L2-PDU field is expected to convey another L2 frame of some kind, minus the frame delineations. This protocol does not specify, suggest, or recommend a specific layer 2 encapsulated frame. However, four such framings are or will be defined on this website: AX.25, ACLP, and MA/CAPS. More are possible. Each protocol addresses a different problem in amateur telecommunications, and demonstrates how AFR can suitably accomodate all of them.
AX.25 packets are maintained in raw form, without frame delimiters, and without any bytes escaped. There is precisely one AX.25 frame per AFR frame. All fields in the encapsulated frame are interpreted according to currently accepted AX.25 practices (see the AX.25 Protocol Specification for more information).
This encapsulation is necessary to free AX.25 from its bit-serial underpinnings, and allow its use on higher throughput and more efficient modulations. The only cost is the additional 0xFF prefix byte.
ACLP is a new packet protocol that is designed to be very simple, inspired by ATM, IP, and ISO-IP. It stands for Amateur ConnectionLess Protocol, and formerly used to be an integral part of AFR, before I realized I could split it from the framing structure outlined above. It provides for support for callsigns up to 30 bytes long, with 8 bits of secondary station ID information. A layer 3 protocol ID field is used to identify the next higher layer. Note that the HEC field (Header Error Check) only protects the header. The data payload may be corrupt, but the packet remains valid as long as the HEC validates the packet header. This allows for higher layer protocols that employ forward error correction to actually correct errors and reduce network utilization from avoidable ARQ activity.
| D/S Lengths | D Address | S Address | L3PID | HEC | layer 3 payload data unit (L3-PDU) |
Both the D and S address length fields are 4 bits each; combined they form one octet (D Length occupying bits 7-4, S Length occupying bits 3-0). Each field indicates how many octets, in units of two octets, the appropriate callsign subfield is in the D- and S-address fields. Both fields may be zero.
Each address consists of two subfields:
| SSID | callsign |
The SSID field is a single octet, and can contain any value from zero to 255. As with AX.25, if the SSID field is left unspecified in an address' textual form, zero is assumed.
The callsign field contains an array of octets which contains UTF-8 encoded strings. Note that if the Address Length field is zero, this subfield doesn't exist, and only the SSID remains. If padding is required (e.g., using a 3-octet callsign), the extra octet is padded with 0x00.
Addresses are expressed in string form, as with AX.25: KC5TJA-4 for example. ACLP SSIDs 0-15 correspond to AX.25 SSIDs 0-15. Addresses are case sensitive, to avoid complexities involved with national/regional collation rules.
An octet value that identifies the layer-3 protocol being carried in the L3-PDU. The interpretation of this field is specific to the ACLP protocol. 0xFF is reserved for future use.
The Header Error Check field is a CRC-8 of the header fields, and protects only the header. If this field mismatches the CRC-8 computed by the receiver, the packet is discarded. Otherwise, the packet is taken, as received, and dispatched to the layer 3 protocol for processing. ISSUE: Can the HEC be used for correcting single-bit errors like with ATM?
ACLP is usable out of the box with CSMA-based MACs. Use with token-bus, DAMA, or MA/CAPS ought to be possible with little or no modifications.
AFR allows conveying multiple types of layer 2 protocols on the same link. If, for example, it is also carrying MA/CAPS frames, it therefore follows that any ACLP transmissions should also be deferred if it would be known to interfere with scheduled MA/CAPS transmissions as well. Therefore, the transmitting node must make every reasonable attempt to avoid collisions.
MA/CAPS is my own interpretation of KA9Q's MACA protocol definition, extended to support scheduling of packets for when it is believed no other node will transmit. As I'm implementing the core functionality right at OSI Layer 2, MA/CAPS is both a protocol name and a link access procedure. Combining MACA with local intelligence of bandwidth utilization will help further quality of service, and is particularly useful for real-time traffic, such as video or digital voice.
Currently there are three kinds of packets: C, D, and R packets.
R-frames are used to request bandwidth for transmitting a packet. They go by the name of "Request To Send," or RTS, frames in KA9Q's document. Bandwidth is "positional," in that not only is a specific quantity of bits requested, but also a specific schedule is requested as well.
| Opcode (0x00) | Octets | Plan | D Length | S Length | D Address | S Address | HEC |
This field is a single octet, containing 0x00, indicating an R-frame.
This field is a 16-bit field, transmitted most significant byte first, containing the number of octets of bandwidth desired by the sending node.
This field is a 32-bit field, transmitted most significant byte first, containing the forward projection of when the data packet is desired to be sent. The unit of time is the microsecond. This field may be zero, representing a request to transmit a packet immediately.
The D- and S-address length fields are four bits each, combined to form a single octet. They represent the number of octet pairs in their respective callsign sub-fields for each address.
The D- and S-address fields actually have two sub-fields, as described in ACLP, above.
As with ACLP, an 8-bit CRC protecting the R frame contents.
C-frames are used to grant bandwidth for transmitting a packet. They go by the name of "Clear To Send," or CTS, frames in KA9Q's document. Bandwidth is "positional," in that not only is a specific quantity of bits granted, but also a specific schedule is granted as well.
| Opcode (0x01) | Octets | Schedule | D Length | S Length | D Address | S Address | HEC |
This field is a single octet, containing 0x01, indicating an C-frame.
This field is a 16-bit field, transmitted most significant byte first, containing the number of octets of bandwidth desired by the sending node.
This field is a 32-bit field, transmitted most significant byte first, containing the forward projection of when the data packet is required to be sent. The unit of time is the microsecond. This field may be zero, representing a request to transmit a packet immediately. Note that, since it takes time to process an R-frame, the Schedule field may be adjusted from the original Plan field to compensate for computation time, thus helping to reduce jitter. It may also be pushed forward, thus delaying a packet (e.g., this is used in LTM-style switching to ensure a packet is transmitted only when a destination route becomes available).
The D- and S-address length fields are four bits each, combined to form a single octet. They represent the number of octet pairs in their respective callsign sub-fields for each address.
The D- and S-address fields actually have two sub-fields, as described in ACLP, above.
As with ACLP, an 8-bit CRC protecting the C frame contents.
D Frames are used to actually transmit data that has been scheduled for the appropriate time. They take a very simple form:
| Opcode (0x02) | L3PID | Length | HEC | layer 3 PDU (L3-PDU) |
This field identifies a D-frame, and must be 0x02.
An octet value that identifies the layer-3 protocol being carried in the L3-PDU. The interpretation of this field is specific to the MA/CAPS protocol.
This is a 16-bit quantity, transmitted most significat byte first, indiciating how many octets exist in the L3-PDU field. This field may be less than the requested bandwidth. This is useful, for exmaple, to provide a guarantee that nothing will collide with another R-frame for the next chunk of data. Through this, isochronous traffic can be supported.
As with ACLP, an 8-bit CRC protecting the D frame header. Note that the L3-PDU is not protected by the HEC, thus allowing layer 3 protocols to be used which are aware of forward error correction.
The layer 3 PDU, containing arbitrary data.
Note that D Frames lack a source or destination address. Since all parties on the network are privy to the R and C frames used to negotiate the bandwidth usage, it is already understood who is sending data to who, and therefore repeating the information here is considered wasteful of bandwidth.
The general idea behind MACA is best explained by Phil Karn himself in his seminal paper on the subject. That paper is strongly suggested reading.
Where MA/CAPS differs from pure MACA is the addition of Plan and Schedule fields in the R- and C-frames, respectively, thus allowing quality of service in an otherwise purely packet-switched network. If the Plan and Schedule fields remain zero, operation is entirely as described by KA9Q.
However, it is strongly desirable that some quality of service be present for medium-speed and even some slower links. Consider the hypothetical case where a number of independent simplex VoP users are on the same frequency. Using Ogg Speex compression, one can achieve 2400bps streaming audio rates on, let's say, 19200bps links. In order to minimize drop-outs, packets from a transmitting station's radio must be sent periodically. To buffer the full keyer's voice transmission will introduce delays often considered to be unacceptable.
Simple math dictates that 19200/2400 = 8 concurrent channels are theoretically possible on the same frequency. Some of these channels can even be used for file transfers (e.g., exchanging maps for those on the road or on emergency communications scenes). In this case, MA/CAPS can be used to coordinate bandwidth utilization between all channel users. ACLP can be used for short packets, where the overhead of an R- and C-frame exchange more than dwarfs the overhead of sending a data inline with normal packet headers.
The way it works is the VoP radio will buffer voice data and compress it until a "voice frame" is filled. Knowing that the data is to be sent at the equivalent rate of 2400bps, but bursts data at 19200bps, a packet will need to be sent every 125ms. So, the VoP radio will initiate its transfer by requesting some bandwidth for immediate transmission.
Assuming it is granted via a C-frame, the VoP radio will transmit a D-frame, followed immediately by another R-frame requesting a similar sized chunk of bandwidth, but to be sent 125000 microseconds in the future. Now all other radios on the network will know that, if granted by the receiving radio, a chunk of bandwidth has been scheduled. They can therefore ensure that they do not transmit any data during that time.
Note that this has a self-synchronizing effect: if the receiving node knows that the D-frame of the transmitter will conflict with another user's bandwidth, it can schedule the frame for just after the blockage. Since relative timestamps are used, massive jitter occurs only for the first packet; subsequent packets tend to remain synchronized. Hence, MA/CAPS is a plesiosynchronous bandwidth allocation method that should deliver good performance for a wide variety of applications.
According to watching the result of the `iptraf' tool on my computer, I can see that connection-oriented taffic out-numbers connectionless traffic by a significant amount, often as much as 1000:1. Moreover, iptraf reports that packets of sizes between 1-75 octets, 300-450 octets, and 1426+ octets are the three most common packet size ranges, with all other packet sizes essentially being noise. For this reason, it seems that an connection-oriented, unreliable protocol that is equally adept with small and large packets alike would better utilize a channel's bandwidth, especially when used in conjunction to with protocols that minimize or eliminate collisions all-together, such as token bus. This is a case of optimizing for the common case.
An AX.25 virtual circuit has an overhead of 18 octets per I-frame. iptraf reports that each character I type is sent out as a single TCP segment. Thus, the equivalent behavior over AX.25 would be 18 octets for the AX.25 header, 20 octets for the TCP header, and another 20 octets for the IP header, totalling 58 octets of overhead. Thus, each keypress involves a packet that has a massive 98.3% overhead. We can completely eliminate the header overhead for TCP/IP by mapping such a virtual circuit connection directly to an AX.25 virtual circuit connection, thus dropping it to 95.2% overhead (including two octets for virtual circuit ID, since AX.25 must rely on a DLCI contained in the PDU to demultiplex the keypress to a specific application on the remote machine). This is a pretty gross waste of network bandwidth!
If we let the layer 2 protocol natively support the idea of a connection, we can get rid of an awful lot of header overhead. With a source address that is 8 octets in size (one length byte, one SSID byte, plus 6 bytes for the average American callsign), and two bytes for the connection ID, we can reduce the overhead to 91.6%. With a network-assigned source address, also two bytes in size, that drops to 83%.
| S Address | Label | HEC | L3-PDU |
My original idea was to let this field consist of an ACLP-formatted address, consisting of a 4-bit length octet (the other four bits would be 0), one SSID octet, and the remaining callsign octets, if any. However, while that cuts the header size more or less in half versus raw ACLP, I felt that it wasn't enough of an efficiency gain.
Using network admittance procedures for token bus, DAMA, or similar networking systems, it should be possible to assign a unique ID to each new node that joins the network. Therefore, my next idea is that this is a LAN-local identifier uniquely identifying the node. A 16-bit field would be sufficient for near any conceivable network. Transmitted most significant byte first. This permits a single LAN to have up to 65535 unique nodes on the network. Address 0 is reserved for network maintanence and admittance control functionality.
The only reason the S Address field exists at all is to support shared and folded bus topologies in ham radio. Without it, all nodes on the network would need to maintain a distributed database of every other node's open connections, which is an O(n^2) proposition I'd rather avoid. Splitting flows into two components of hierarchy allows us to reduce the memory requirements to just O(n), and even then, only for those connections that you are participating in.
Regardless of S Address format, the label is a 16-bit field (MSB first) which is scoped by the S Address field. This field identifies a unique *outward* flow of traffic from the node to some destination. Hence, a single bi-directional flow of data consists of two unidirectional channels, each identified by their own S Address:Label pair.
Note that both the S Address and the label are link-local in scope. Thus, it is possible to route traffic between multiple switches using label translation techniques quite similar to ATM and Frame Relay. This is quite unlike AX.25, MA/CAPS, or ACLP, where the layer 2 addresses are not routable.
Note that there is no L3-PID field. This field is not necessary, since it would be specified in the connection establishment procedure. Therefore, there is no need to constantly repeat that information in each packet intended for that connection.
A single octet containing a CRC check of the ACOP header information only.
ACOP is intended to be used in conjunction with ACLP on the same link. See ACLP for more information on supported link access procedures.
All special-purpose, network management functions are carried out on label=0. All other labels are allocated by the source node as it sees fit (just as TCP allocates source ports).
One possible way to establish a connection using only ACOP is as follows. Connections are established by first allocating a new label, then sending a Connection Request message on SrcAddr:0. This message will contain the destination node address, L3PID, and other related information necessary to establish the connection. It must also include the source's assigned label as well, so that the destination knows what it is to accept future traffic from the source!
If it accepts, the destination responds with a message to DstAddr:0, including the source address, the destination's own label, etc. If it rejects the connection, it issues a reject message to DstAddr:0.
If a datagram message needs to be sent, then one of two things can happen. One, send a special datagram message to Addr:0. Alternatively, take advantage of AFR's multi-protocol capability and actually use ACLP to send the datagram. The latter is preferred if possible, since it's lower in overhead. Therefore, header overhead is spent only when actually required.
I can't see how I forgot to include this. I am an absolute firm believer that every layer in the network stack needs to have some form of loopback test capability. That's what this frame type is for.
| D/S Lengths | D Address | S Address | Message |
As you might expect, bits 7-4 contains the D address length, while bits 3-0 contains the S address length.
As with ACLP.
A message, not to exceed 128 octets. If the message exceeds this length, it is truncated at the receiver.
Primarily expected to be CSMA, since it's for testing the link on a very low level. I doubt this would ever be used in a DAMA or token bus network, where layer-3 loopback testing is almost certainly going to be used instead (since it's already established that layer-2 already works). Layer 2 echo tests is analogous to "going intrusive" on a T1 circuit. Unless the rest of the network is also CSMA, use of this frame type will almost certainly disrupt normal network operations.
There are several kinds of frames associated with token bus. For connectionless data frames:
| Opcode (0x00) | D Length/Address | L3PID | HEC | L3PDU |
Note that there is no source address in data frames, because it's implied in the token pass operation! For connection-oriented frames:
| Opcode (0x01) | VCI (0x0001-0xFFFF; as per ACOP) | HEC | L3PDU |
Again, no source address is needed to qualify the VCI because it's implied in the previous token pass operation. For token passing itself:
| Opcode (0x02) | D Length/Address | HEC |
For token claiming:
| Opcode (0x03) | S Length/Address | HEC |
For network admission:
| Opcode (0x04) | S Length/Address | HEC |
For network departure:
| Opcode (0x05) | S Length/Address | HEC |
For network admission or departure acknowledgement:
| Opcode (0x06/0x07 for ACK/NAK, respectively) | D Length/Address | HEC |