Re: RFC1226 - Internet Protocol Encapsulation of AX.25 Frames - Thread - go-pugleaf

Thread View: dnet.ham

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by uunet!samsung!swlvx2!anomaly.sbs... Fri, 17 May 1991 04:13

Re: RFC1226 - Internet Protocol Encapsulation of AX.25 Frames

#207

Author: uunet!samsung!swlvx2!anomaly.sbs...
Date: Fri, 17 May 1991 04:13

42 lines
2763 bytes

I generally agree with Anders' (Anders.Klemets@cs.cmu.edu) thorough reply to
my comments, but there are a few things I want to clarify.

With regard to timing, the IP bridge could take quite a long time.  There is
nothing that would prevent the establishment of an IP bridge over long
distances, even via satellite.  AX.25 fixed length timers do not allow this.
Although dynamically adjusting timers are in common use (in NOS, for example),
the formal protocol document specifies fixed length timers.  (See 2.3.5.4 of
the protocol.)

My suggestion about prohibiting digipeating across the IP bridge was meant to
encourage methods of routing other than digipeating.  In particular, if the
IP bridge acted like a NET/ROM node, the timing problem and so forth would
be solved, since the AX.25 timers would only have to run on acknowledgments
from each AX.25 user to the IP bridge, rather than end-to-end.  (Don't read
this as an endorsement of NET/ROM, but I'm making a point.)

Under no circumstances do I think that the AX.25 users should have access to
the routing information inside the IP bridge, such as the IP address of the
destination of frames travelling within the bridge.  What the AX.25 users
know can hurt them.

Again, I emphasize that digipeating is supposed to be phased out (in theory)
in favor of a more traditional ISO layer model.  Tying this RFC to the scheme
used for digipeating may cause trouble.  Here is the protocol speaking:

     These repeater stations simply extend the RF range of Amateur Radio
     stations.  Since they do not impose any flow controls, data switching,
     or routing, their inclusion at this layer does not imply any network-
     layer functions.  It is anticipated that repeater stations will be
     phased out (or at least their number greatly reduced) when a true
     network layer becomes operational.  (from Preface, "not a part of the
     protocol.")

As to the CRC issue Anders raises, it must b



e "calculated in accordance with ISO 3309".  (See 2.2.7)

-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA  (AX.25)
               mikebw@idsvax.ids.com  (Internet)

Re: RFC1226 - Internet Protocol Encapsulation of AX.25 Frames

#201

Author: Anders.Klemets
Date: Fri, 17 May 1991 04:42

42 lines
2647 bytes

> With regard to timing, the IP bridge could take quite a long time. 
There
> is nothing that would prevent the establishment of an IP bridge over
long
> distances, even via satellite.  AX.25 fixed length timers do not allow
this.

Possibly. But note that an IP bridge is never "established." The bridge
would not use any connection oriented transport protocol, such as TCP.

A 256 byte AX.25 frame takes about 2 seconds to transmit on a 1200 Baud
channel, including TXDELAY.
However, the time to transport such a frame over the Internet from, say,
Sweden to eastern USA would only be about 100 ms. It used to be as bad
as 500 ms, but that is still just a small multiple of the TXDELAY.

So the total transmission time of the frame should be dominated by the
time it takes to transmit it on the radio channels at both ends of the
connection.

So, adding one digipeater to the frame would get the transmission delay
of TNCs just right. It would also make it fairly convenient for the user
of the TNC to access the IP bridge. The user can have his packets
'digipeated' by the bridge just by typing the right callsign sequence at
his TNC command prompt.

Using no digipeaters (read: the NET/ROM model) the originating user
would have to make an AX.25 connection to the bridge and send connect
commands to its user interface. I think most users would find that to be
more impractical. It could also make it complicated (or impossible) to
have the bridge relay AX.25 UI frames.

I can also imagine a third scheme where you don't need to connect to the
bridge, and you don't need to use a digipeater to specify that you want
to use the bridge. The bridge would just "know" which callsigns it
should relay. Although this might sound neat, I think it could cause a
lot of problems. One would get the timing problems on TNCs for instance.
And particularily strange things would happen if two stations that
communicate through the bridge suddenly start to hear each other
directly. We all know how propagation conditions tend to vary...

Anders

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads