Date: February 2, 1996

Status: Initial Release

Introduction

The AX25 Link Layer protocol has been very stable and has not undergone any significant changes in the recent past. The networks and users are now reaching a point where additional services are being asked for, such as compression. The AX25 protocol as it now stands does not lend itself well to having a variety of optional services. The current method is to have the application define a negotiation technique, such as is done with the various BBS software during forwarding cycles. There are other capabilities that could be utilized if there were a standard method for signaling the presence of the control information to specify or configure their use. The only way that any such proposal will gain any kind of acceptance is if it only requires minor changes to the existing AX.25 protocol.

The goals were:

1. Remain consistent with the existing specification.
2. Require as few changes as possible to conform to the extension.
3. Backward compatibility.
4. Flexibility.

The solution presented meets these goals and provides the ability to negotiate or identify support for an unlimited number of additional capabilities.

Negotiation Extensions to the AX25 Link Layer Protocol

The two Reserved bits in the SSID of the Source and Destination Callsigns are used by these extensions.

The existing Version 2.0 spec would only require changes in sections 2.2.13.1, and 2.2.13.1.1, in the references to the reserved bits of the SSID bytes of the address field. These previously reserved bits were being set to '1's.

Bit 5 (previously reserved) is now referred to as the 'N' bit, and when cleared indicates the ability of that AX25 station to support Q Bit Data Negotiations.

Bit 6 (previously reserved) is now referred to as the 'Q' bit, and is only cleared for 'I' frames that are being used to pass Q Bit negotiation data (optional features). When the 'Q' bit is cleared it indicates that the data in the I frame is being sent as Qualified Data. This data is always sent 'In the Clear' and the format is defined another document. (TBP)

Also, in section 2.2.13.2, subsection 3 is changed to 'The "R" bits are reserved.' Previously this sentence also had 'in the same manner as in the source and destination subfields', which no longer applies.

STATIONS OF ORIGIN AND DESTINATION

Any station that supports negotiations, when making a connection , will clear the 'N' bit on the source address of their 'SABM' frame. The other address (destination), would have the 'N' bit set as it currently is defined. The originator can only 'speak' for himself, so he leaves the 'N' and 'Q' bits alone on the destination station SSID.

When a station that supports negotiations receives a connection request it should respond with the 'N' bit cleared on the SSID of it's callsign (origin) and should send the 'N' bit of the destination as it was received in the 'SABM'.

All optional digipeater SSID are always sent as per the current spec R=1. The usage of the RR bits in a digipeater field when both the Source and destination 'N' bits are cleared is reserved for further study. This document places no restrictions upon the R bits when one or both of the 'N' bits are Set.

All frames after the 'UA' should have both 'N' bits cleared. Any other setting will imply that the Q Bit Extensions are not supported and are beyond the scope of this document.

All frames sent by Negotiations Compatible software should have their 'N' bit cleared, regardless of the ACTUAL USE of any particular facility (feature). The clearing of this bit should not be used to assume the state of any facility, just that the unit supports negotiations.

Either side, at any time, can send Q Bit Data. This is done by sending the negotiation information in the data portion of an 'I' frame, and clearing the 'Q' bit of their sending SSID, as well as the 'N' bit.

This Q Bit Data could, depending upon assignment, be a Request to negotiate a Compression protocol or it could be Service messages such as "Link Reset possible data loss". If the Q Bit data is a Request that requires a Response the system sending the Request should be able to recover if the receiving station does not support the specific Request. The formatting of the Q Bit Data frames and Error codes is covered in another document.

No Q Bit Data frames can exceed the size of any normal 'I' frame supported by the two stations and any intervening network involved (generally 256 bytes).

Negotiation frames are ALWAYS sent normalized, that is, all data frames for negotiations are send WITHOUT the use of any negotiated facilities. For instance, even if compression is being used, the negotiations are send UN-compressed.

The ability to send 'normalized' data is available at any time, that is, data that does NOT use ANY of the negotiable facilities. This is explained in the document describing the Q Bit Data format.

DIGIPEATERS

No special steps need to be taken in Digitally Repeating (digipeating) any frame using these extensions, other than assuring that the state of the 'N' and 'Q' bits in ALL SSIDs are passed through as they were received. The 'N' and 'Q' bits for digipeater fields will ALWAYS be set by the sender (as they were prior to these extensions), and they should remain set when repeated by the digipeater device. While this is NO different from the action specified by the AX25 v2.0 spec, software exists that did not fully meet this portion of the spec, and since these bits were not previously being used, it was not evident that there was a problem in this area.

NETWORK SOFTWARE

Network software generally DOES NOT directly speak to the endpoints, but instead pass data transparently from source to destination. Networks, though more complex, seem to the endpoints essentially the same as digipeaters, and as such should follow the same procedures as digipeaters. No restriction is placed upon how the network communicates the 'N' and 'Q' bit settings as long as they are passes transparently.

In addition, network firmware can send and receive Q Bit Data from/to either endpoint, and can 'eavesdrop' on Q Bit Data sent between the two endpoints for possible negotiations intended for the network.

This provides the ability for the endpoints to handle end-to-end facilities with the data passing through the network transparently, or the reverse, in allowing the endpoint to negotiate directly with the network for certain facilities that the other endpoint may not be capable of.

For example, if the endpoints supported a better compression scheme than the network, it could negotiate for end-to-end compression, and the network would simply pass the data through transparently. But, the originator COULD negotiate to use compression TO the network on a point-to-point basis, even if the destination station did NOT support compression.

BASIC GENERAL RULES

1. No station along the digipeater path should change the state of either the 'Q' bit or the 'N' bit on ANY SSID from how it was received.
2. Any intervening network should pass the 'Q' and 'N' bit information transparently and maintain frame boundaries for all frames with the 'Q' bit cleared.
3. No support is given in these extensions for negotiated facilities using UI mode. Use of these facilities with UI frames is for further study.
4. The 'Q' bit should be set on ALL control frames, and should ONLY be cleared on 'I' frames containing Q Bit Data.

LEVELS OF SUPPORT

There are two levels of support for the negotiation extensions of AX25 v2.0:

Negotiation Transparent This involves actually no more than conforming to the original spec in regards to the 'N' and 'Q' bits. These bits should be handled as follows:

1. not be assumed to be set
2. be passed (when digipeating) as they were originally sent
3. not cause any kind of condition of error or data loss if they are NOT set.

In most cases, a non-network level software product is already Negotiation Transparent, or can be made Negotiation Transparent.

Negotiation Compatible This indicates not only Negotiation Transparent, but also able to send/receive negotiations. Trace displays use the specified notation for the 'N' and 'Q' bits. The level of impact on a software product for this will be determined on the number of facilities supported, and the number of variables for each of these facilities.

EXAMPLE INTERACTIONS

This text is not part of the protocol extensions, but is provided for clarity. The notation used is only one possible technique and the various implementors may choose to display the callsigns in a different, possibly better scheme. The following examples will include the three major classifications of networks; Pure Digipeater, Pass-Through Switch and Point by Point Node. The typical implementations of these are: Digipeater, ROSE Switch and Net/Rom Node. In the network examples it is important to note that in the initial interaction between the station of origination and the network is only indicating if it supports the 'N' and 'Q' bits. If the final destination does not support the extensions it would be reasonable for the Network to return an CIF Error message for any data that should have been forwarded to the destination with the 'Q' bit cleared.

TRACE NOTATION

An address with the 'N' bit cleared is displayed with as CALL+SSID (i.e., KO4KS+15) and an address with the 'N' bit set, is displayed (as previously) as CALL-SSID (i.e., KO4KS-15). If the SSID is 0 and the 'N' bit is cleared, it is displayed as CALL+ (i.e., KO4KS+).

The same scheme is used for Q Bit Data (when both the 'N' and the 'Q' bit are cleared) using a '#' instead of a '+'.

EXAMPLE 1: Directly Connected Stations

N4XXX-1 W4YYY-2

N4XXX+1->W4YYY-2 SABM -->

<-- W4YYY+2->N4XXX+1 UA

<-- W4YYY#2->N4XXX+1 I

N4XXX#1->W4YYY+2 I -->

EXAMPLE 2: Stations using one (or more) Digipeaters

N4XXX-1 DIGI-9 W4YYY-2

N4XXX+1->DIGI-9->W4YYY-2 SABM -->

N4XXX+1->DIGI-9->W4YYY-2 SABM -->

<-- W4YYY+2->DIGI-9->N4XXX+1 UA

<-- W4YYY+2->DIGI-9->N4XXX+1 UA

<-- W4YYY#2->DIGI-9->N4XXX+1 I

<-- W4YYY#2->DIGI-9->N4XXX+1 I

N4XXX#1->DIGI-9->W4YYY+2 I -->

N4XXX#1->DIGI-9->W4YYY+2 I -->

Example 3: Stations using a ROSE Network

N4XXX-1 W4SW-3 ==== Backbone ==== W2SW-3 W2YYY-2

N4XXX+1>W2YYY-2,W4SW-3,201338 SABM -->

<-- W2YYY+2 > N4XXX+1,201338,W4SW-3 UA

N4XXX#1>W2YYY-2,W4SW-3,201338 I -->

<-- W2YYY+2 > N4XXX+1,201338,W4SW-3 UA

N4XXX+1>W2YYY-1,813878,W2SW-3 SABM -->

<-- W2YYY+2 > N4XXX+1,W2SW-3,813878 UA

<-- W2YYY#2 > N4XXX+1,W2SW-3,813878 I

N4XXX#1>W2YYY-1,813878,W2SW-3 I -->

Example 4: Stations using a Net/ROM Network

N4XXX-1 W4NOD ==== Backbone ==== W2NOD W2YYY-2

N4XXX+1 > W4NOD SABM -->

<-- W4NOD+ > W4XXX+1 I

N4XXX+1 > W4NOD I -->

<-- W4NOD+ > W4XXX+1 I

N4XXX+1 > W4NOD I -->

<-- W4NOD+ > W4XXX+1 I

N4XXX#1 > W4NOD I -->

<-- W4NOD# > W4XXX+1 I

W2NOD+ > W2YYY-2 SABM -->

<-- W2YYY+2 > W2NOD+ UA