Re: Networking with IP

[samst@bdol10.indepth.com (Steve Sampson)]

I've received some comments on the IP only submission and would like to
comment on my thinking.  It may be too low tech, and you can grill
me on that.

One of the problems with dropping AX.25 is there would be no way to
target a node that you wish to repeat the packet.  You need something
that ARP could get its teeth into.  I had this in mind when I was
reading the RFC 971 (I think that's the one on IP):  What does IP
have that could replace this routing problem? Was the question.

Reading the section about Loose Source and Strict Source of the Option
field seems to fit the bill.  I figure at most you will need 5 or so
intermediate hops from one major NOS router to another NOS router.  In
this case the Strict Source Option would allow you to specify the
route exactly.  It's not dynamic, and it's not high tech, but it does
seem interesting as a solution.  Basically the whole route is added to
the IP frame (20 bytes or so in this case), and each node pulls its address
off and sticks the next one into the destination address from the attached
list.  But I would guess the majority of network nodes would be not need
any of this if they switched frequencies at each node to avoid the Hidden
Terminal problem, or to go full duplex; Just those long runs over the
prairie or mountains.

Well anyway, I figured - yea right, that will take a lot of programming.
So I looked into the JNOS IPROUTE.C and found that it was already there.
The real addition is the changes needed to create the Source Option
structure to add on.

I think of this as point-to-point, but that's not really a good name in
this method.  Point-to-Point with Intermediate Routing attached?

So where is the advantage?  Well if you had 4 intermediate routes you
pass through the AX.25 header size, and that wouldn't offer any advantage
other than the lack of bit shifting to find out the callsign.  You could
save about 50k of NOS binary by removing AX.25. That's only 8% of PC 640k,
and insignificant in Linux, and probably the TNC also, because the 32k ROM
can't be used for anything else but code anyway.  Doesn't look too promising,
until you add up the time spent in adding and subtracting all the different
encapsulation algorithms.  Looks like a computer time vs number of bytes
per header tradeoff, with no data on which would be faster. My only
satisfaction is that you get away from connected mode and resort to
datagrams only at the link level.

--
n5owk