On Mon, 3 May 1999, Tim Salo wrote:
> Well, the PID is actually a rather odd construct.
>
> First, I don't think the PID was ever part of the CCITT X.25 Recommendation.
> Rather, it is specified in X.29, (and mostly in a lot of non-CCITT PAD
> documents).
>
> Second, AX.25 could more appropriately be called A-HDLC, in that AX.25
> uses only the HDLC portion of X.25 and contains none of the packet-level
> protocol of X.25.
>
It seems to me that the PID constuct is similar to the protocol identifier
in Ethernet. On these cases you have for every frame sent the protocol
signature, and this is obvious because on these protocol you normally use
unconnected frames (if you are using Ethernet II protocol you have only
unconnected frames). Some services (ie. IBM SNA) are using IEEE 802.2
packets ,and in this case the PID is repeated in every frame (twice),
even if SNA uses LLC and a connected reliable service (this make the
packet demultiplexing stateless).
Back to AX.25: jnos accepts IP frames intermixed with text frames on
the same ax.25 connection. Linux doesn't like this (I haven't tried hard
to check it, but if you have a connection you can't reuse it from another
task).
Now, IMHO compression is useful at low bit-rates, ie. for user stations,
rather than for high-speed interlinks. So an end-to-end negotiation could
be useful. We can add a PID for compressed-ax.25 text and one for
compressed-ax.25 IP. Then attach in a netrom-like manner the compressed
interfaces to the normal ax.25 drivers.
Mike
