🚀 go-pugleaf

Mike,

> does the IP bridge get a pseudo-callsign so that it is explicitly
listed in the > AX.25 frame as a pseudo-digipeater?

Yes, that sounds like a way to do it. You can also have the bridge treat
callsigns in the same way that NET/ROM does. The RFC does not dictate
how a bridge should be implemented, so I guess you have several
alternatives.

> 3.  How do we handle the AX.25 timers across the IP bridge?  Shouldn't
> we at least require that the timers be adjusted dynamically from end
to 
> end on the AX.25 circuit? What happens if regular AX.25 people try to
> communicate with each other over the IP bridge using standard
> fixed-length timers, especially ones that are too short?

I suspect most Internet bridges would transport the packet faster than
what it takes for the packet to pass a 1200 Baud digipeater. However, if
the packet is being rebroadcast on a radio channel using the same speed
as on the entry level channel, the delay will be comparable to at least
one digipeater hop.

The best way to get the timers right would of course to use a modern
AX.25 implementation that uses dynamic round trip time estimates. But to
accomodate those who use old TNCs, the IP bridge should probably require
one 'dummy' digipeater callsign. This extra callsign maybe be used for
routing, like is being done by ROSE switches. (The callsign could for
instance be an ASCII encoding of the IP address of the end-point IP
bridge.) But it would of course be much better if the bridge itself
could keep track of where to route AX.25 frames for a given destination.

> 4.  If we want to avoid the problems of 2 and 3 above, should we
prohibit
> the carrying of digipeated frames across the IP bridge? 

No, I can't see that there would be a point in doing that. The more
digipeaters the better if you are using a TNC.

> what happens when an AMPRNET or NET/ROM circuit must use the
> IP bridge? ... And can this go on for any number of iterations?

It would work just fine, but you would have to cope with the packet size
limits of AX.25 and NET/ROM.

> Would there be any loss of functionality by requiring that AX>25 users
> who want to use an IP bridge encapsulate their data in IP frames, as is
> done on AMPRNET, rather than the reverse as proposed by this RFC?

Maybe not in theory, but in practice all AMPRNET stations have network
44 IP addresses, which is a single Class A network. The network can only
have one gateway to the Internet. Wherever you put this gateway it would
always be unfair to lots of people, because AMPRNET is not fully
connected. 
By gatewaying AX.25 frames from AMPRNET through third party IP networks
it could however be possible to make AMPRNET fully connected. It would
then not matter very much in which country or state the gateway between
AMPRNET and the Internet is.

> is there anything in this proposal that creates a hidden tie to AX.25
> version 2.0?

The RFC seems to dictate the use of a CRC-CCITT frame check sequence.
Should AX.25 ever change to use something else, it will conflict with
the RFC. (Actually, I thought AX.25 used CRC-16, but I could be wrong.)
And the RFC does not describe any method to distinguish between
different versions of AX.25. Hopefully it will be possible to determine
which of any future versions is in use just by looking at the AX.25
header.

Anders