Ber# TR Lengte Aan Van @ BBS Datum/tijd Titel 195 BN 6490 AX25 PE1AUE EUROPA 0410/0236 Nieuwe AX25 ??? R:880410/0341 @:PA3AYB #1293 [Forwarding - PA3AYB - Putten - R.34] R:880410/0117L @:PE1ABT #1097 [FWD PE1ABT - Zaltbommel - EURO-PA #5#] R:880409/2107t @:PE1AUE #697 Date: 19 Jan 88 05:16:21 GMT References: <8801181533.AA08932@decwrl.dec.com> Organization: Bell Communications Research, Inc Lines: 98 Summary: new link protocols I'm glad to see that I'm in some company when it comes to wanting to replace AX.25. An ARRL-sponsored meeting had been scheduled in northern Virginia a weekend ago to discuss both short-term compatible changes to the current AX.25 (AX.25 Version 2.x) plus initial long-term proposals for a new protocol, one that would necessarily be incompatible with the old. (This new protocol has the working title AX.25 V3.0?, but more about this later). However the meeting was snowed out, and a new date hasn't been set yet. One proposal (from the Radio Amateur Telecommunications Society in the northern New Jersey area) has already been floated. Others would be most welcome. What follow are my own comments and ideas, not to be confused with those of RATS (not that there's much chance of this happening! :-)) Before I start bashing AX.25, though, there is one thing I believe was done *right* in its design, and that was the addition of a datagram- style address layer to each packet. This avoided so many problems, and has worked so well in practice, that it's hard to remember that anyone ever proposed "dynamic addressing" link protocols seriously. (The really fun part about all this is that the Founding Fathers Of AX.25 were and still are firmly in the "virtual circuit" camp, and to this day they vehemently deny having contaminated AX.25 with any datagram-like principles :-) ). The main problem with AX.25 as it now stands, and the main reason for the work on a new protocol, is the hard limit on callsign length: 6 characters. This is not a problem for most amateurs, but those required to identify with suffixes (temporary and reciprocal licenses, etc) are stuck. Fixing this implies a complete redesign of the addressing sublayer. In the process, we might as well do the whole thing right, since it will be incompatible with the present protocol anyway. So here are some thoughts about how to design a new protocol from the ground up. 1. The boundary above the datagram (address) sub-layer should be more clearly defined. The C-bits in AX25L2V2 (for which I take full blame) are a gross and disgusting hack because they carry information that properly belongs in the LAPB control field, not the address field. (I confess to taking CCITT at its word when they called the byte ahead of the control byte the "address octet", even though X.25 runs on point-to-point links where link level addressing has no meaning. I was young and naive then, and I hereby throw myself on the mercy of the court. :-) ) 2. There should be a protocol identifier field between the address field and the control field so that protocols other than LAPB can be used. It sort of works now with the UI (unnumbered information) frame, but it's "unclean". This translates into wasted header space and messier function-call interfaces between the various layers (I know, I've implemented this stuff). 3. The use of "bit shifting" in the present address field is a classic example of blind subservience to "international standards". ("Why was it done?" "Because ISO said so.") It bought absolutely nothing in terms of compatibility with anything else, but it created a low but persistent irritation factor (double ascii displays on trace dumps, extra code, etc). Furthermore, the information carried by the low order bits (the length of the address field) could have been encoded in fewer bits by just putting it in a count field. This also saves the CPU from having to scan each byte to find the end of the address field, something that will become important at high speeds. 4. Along the same lines, store-and-forward digipeaters (which won't go away completely, no matter how much we would like them to) should make their mark on packets by incrementing a "pointer" field in the address header rather than by setting has-been-repeated bits scattered throughout. This is how it's done in IP source routing, and it's also a lot faster to process. 5. The protocol should be more streamlined for connectionless network traffic. (Except for COSI, every amateur network layer protocol at present is connectionless). One should not have to go through a "null" LAPB layer to run the link in connectionless mode; that was my reason for suggesting a protocol ID field directly after the address field. Even if a connection-oriented protocol like LAPB is used to provide link-level acknowledgements, it should allow data in connect-request packets. This would be much like the "fast select" feature found at the network layer in X.25. 6. Asynchronous framing should definitely be an option. HDLC is nice, and now that we have it we might as well use it, but it should not be the only way things can be done. SLIP-style framing plus a suitable checksum would work just fine at low speeds. (SLIP is already used on the asynch port between a host computer and a KISS TNC). 7. Last but not least, we must name the new protocol something other than "AX.25". This is a serious misnomer even for the present protocol, as it misleads people into assuming it to be a compatible subset of CCITT X.25 in the way BX.25 ("Bell X.25") is. It isn't, and we're likely to diverge even further as we learn just how different the needs of amateur packet radio are from the wants of landline common-carriers. Furthermore, because of its CCITT connotations, "AX.25" is often downright embarassing to those of us trying to establish the legitimacy of amateur packet radio to our non-amateur peers in the more progressive communications research organizations. :-) Comments? Phil