dna@dsd.UUCP (02/28/84)
To: All Packet Stations
From: Phil Karn, KA9Q
Subject: P/F bit (again!)
With the Trenton Packet Radio conference
coming up again soon, I think we are going to be forced to settle the
issue of proper poll/final bit usage in AX.25 once and for all.
For those of you unfamiliar with the problem, here's a short primer. The
P/F ("Poll/Final") bit in the control field of each X.25 level 2 frame
is provided for asking the status of the other end of a link,
particularly after a timeout. Since the Poll (inquiry) and Final
(response to inquiry) functions share the same bit, resulting in
identical control fields, the distinction is made in X.25 LAPB
point-to-point links by looking at which address (yours or his) is
present in the address field. If it contains your address, the frame is
a poll command to which you must respond; if it contains the other
station's address, it is a response to your poll. The distinction is
necessary because both stations might poll each other simultaneously, a
very likely possibility if a momentary link failure or QRM affects both
transmission directions.
Unfortunately, when we invented the addressing scheme for AX.25, we lost
this information. The address fields are always the same - they contain
both callsigns. Therefore you cannot reliably determine if a frame you
receive with the P/F bit set is a command or a response. While X.25 LAPB
does provide for an alternate way to recover after a timeout (by sending
ONLY the oldest unacknowledged I-frame in hopes of generating an S-frame
response with an indication of what the receiver expects) there are
other situations which require a better solution.
1. The current TAPR implementations appear to send ALL unacknowledged
I-frames after a timeout, which is forbidden under LAPB. This can
result in inefficient use of the channel, particularly if the timeout
was due to the receiver's acknowledgement being lost.
2. When the remote end becomes busy (say, due to a slow printer), it
sends a RNR (receiver not ready) to flow control the sender. LAPB
requires the sender to wait for a RR (receiver ready) before sending
more information. It is SPECIFICALLY FORBIDDEN for the sender to send
any more I-frames before getting explicit permission from the
receiver in the form of the RR frame. Since this RR frame could get
lost, the sender could wait forever; therefore it is strongly
recommended that the sender take the responsibility of periodically
polling the other end to see if the busy condition still exists.
Polling with the P/F bit takes much less channel bandwidth than sending
unwanted I-frames in the hopes that the receiver might be ready for them.
Unfortunately, in the TAPR implementation, it appears that the sender
periodically resends all the I-frames which the receiver could not
accept, over and over again, until the receiver can finally take them.
Besides being in violation of the protocol, this uses the channel
inefficiently. Right now, this isn't too much of a problem because our
links are generally slower than our computers or terminals. However,
when our link speeds surpass our computer or terminal rates and flow
control becomes common, we'll find ourselves wasting a lot of the extra
channel capacity on retransmitted I-frames. Clearly the problem must be
solved.
Therefore, I would like to formally propose the following modifications
to the standard. Basically, I am proposing that we use some reserved
bits in the SSID byte of the source and destination address fields to
contain the information formerly provided by the address field of X.25
LAPB. This can be done in an upward compatible way, preserving
compatibility with existing implementations of AX.25.
For the purposes of this section, bits within octets (bytes) of the
address field are numbered from 1 to 7, with bit 1 being the least
significant bit (the address extension bit.) Currently, the AX.25
standard calls for bits 6 & 7 to be reserved and set to 1. I would now
define a use for bit 7 of the source and destination SSID bytes; bit 6
in all address SSID bytes would remain reserved and set to one, while
both bits 6 & 7 in repeater SSID bytes (if any) would remain reserved
and set to one.
An upward-compatible AX.25 station would determine if the station it is
in communication with also has the "new" standard by comparing bit 7 in
the source address SSID with bit 7 in the destination address SSID of
received frames. Since the present standard calls for these bits to be
set to 1, equality would indicate that the other station is an "old"
implementation and the "new" station would act accordingly (i.e.,
according to present procedures).
However if the bits differ, it can then determine if a given frame is a
command or response by whether the source or destination SSID field has
bit 7 set, using rules analogous to LAPB. In other words, if LAPB would
call for a given frame to be sent as a "command", i.e., with the other
station's address in the address field, bit 7 in the destination SSID
byte is set to one and bit 7 in the source SSID is set to zero. If LAPB
would call for the frame to be send as a "response", bit 7 in the source
SSID would be set to one and to zero in the destination SSID.
Summarizing in tabular form:
X.25 LAPB addressing rules:
Direction Command Response
A->B B A
B->A A B
AX.25 (revised):
Command (either direction)
dest SSID bit 7 src SSID bit 7
1 0
Response (either direction)
dest SSID bit 7 src SSID bit 7
0 1
Note that the same callsign (that of the commanded station) would have
bit 7 of its SSID set in both the command frame and its response.
This is because the commanded station's callsign occupies the destination
field of the command, while it occupies the source field of the response.
On the other hand, bit 7 of the commanding station's SSID byte would
be zero in both the command and response frames.
Since all X.25 frames are classed as either "commands" or "responses",
even when there is no ambiguity (e.g., I-frames are always commands),
all AX.25 frames should also be marked as such.
This proposal has the following advantages:
1. Upward compatibility with existing implementations of AX.25 which
comply with the "old" requirements concerning the reserved SSID
bits.
2. Conceptual conformance to LAPB with respect to "commands" and
"responses" when communicating with other stations also following this
"new" protocol. The AX.25 address which is "marked" by bit 7 in its
SSID byte corresponds to the choice of address "A" or "B" which would
normally be used in LAPB. This allows much closer adherence to
well-established LAPB procedures for link recovery and flow control, and
much better channel utilization under these conditions.
3. Minimization to the greatest possible extent of the procedural
differences between AX.25 and CCITT X.25 caused by the former's
specialized addressing scheme. This would allow cleaner implementations
that draw upon existing procedures developed in non-amateur X.25
networks.
Comments, constructive flames, etc, are invited.
73, Phil