[nos-bbs] A.X25 then, A.IP

[KV9U]

I am very weak on understanding much of the NOS stuff, but I got the 
impression that we had to encapsulate TCP/IP within an AX.25 packet to 
make it practical on RF circuits. Perhaps you folks are already familiar 
with this URL, and could comment on it:

http://www.mitre.org/work/tech_papers/tech_papers_00/wickwire_performance/wickwire.pdf

At Field Day, one of the other guys who shares my interest in practical 
emergency communications, and who works primarily with some pretty 
sophisticated (read, expensive) military applications, is always looking 
at different solutions to make up a network that could interoperate with 
WiFi, D-Star, or plain old packet. The problem we have is that due to 
our terrain, we have widely varying elevations from about 600 to 1200 
feet and even VHF 9600 would be difficult to do in one hop across the 
county.

73,

Rick, KV9U



Barry Siegfried wrote:

>[Tim Gorman <ab0wr at ab0wr.net> wrote]:
>
>  
>
>>Been doing a bit of thinking on this.
>>
>>AX.25 is a Layer1/Layer2 definition.  It is based on the concept of links
>>at Layer2 between two endpoints (with two digipeaters also possible).  It
>>is this concept that allows sharing of a packet channel by several
>>conversations through collision avoidance routines built into the link
>>layer.
>>
>>The move from X.25 to ip was facilitated in the wired network by other
>>developments - primarily the wide introduction of ethernet and token ring.
>>These provided the Layer2 data link functions for the Layer3 IP protocol
>>to use.
>>
>>The corresponding concept in amateur radio was to carry the Layer3 IP over
>>the existing Layer2 AX.25 data link setup - i.e. IP encapsulation in AX.25
>>frames.
>>    
>>
>
>I think Tim has this down pretty well.  :)  As a matter of fact, I'll go
>one step further:  The function of AX.25 ("low-level" layer 2 or the
>Medium ACcess sublayer) over RF (layer 1) is equivalent to using ethernet
>(Medium ACcess sublayer) over wire (layer 1).  By definition, ethernet is
>a "broadcast" medium (as is RF) and the two are functionally equivalent.
>AX.25 addresses (i.e. callsigns) over RF serve an identical purpose to
>using ethernet addresses (i.e. MAC addresses) over wire.  The only
>difference is that we have HTS (hidden transmitter or terminal syndrome)
>and path noise on our RF links which we don't have on wire.
>
>  
>
>>What you are proposing is getting rid of the AX.25 frame information as
>>being too much overhead.  We need to define what this discardable overhead
>>is.
>>
>>An AX.25 frame consists off:
>>	Start Flag
>>	Address block (source, destination, 2 digipeaters)
>>	Control block (type of frame, sequence nbrs, etc)
>>	Protocol ID block (ax.25, tcp/ip, net/rom, flexnet, etc)
>>	Information block
>>	HDLC Frame Check block
>>	End Flag
>>
>>You could certainly shorten the Address block since source and destination
>>IP addresses will exist in the IP frame.  The Control block information is
>>needed, however, for controlling the ability to share the channel among
>>numerous users.  Not so easy to discard parts of it.
>>    
>>
>
>No, and it is also needed to "bridge the gap" between AX.25 ("low-level"
>layer 2 or MAC) and LAPB ("high-level" layer 2) since the AX.25 spec lacks
>a proper protocol ID field (byte) between the "low-level" address (MAC)
>and "high-level" (LAPB) sublayers.  A control value of "UI" indicates
>that LAPB ("high-level" layer 2) is to be bypassed.
>
>  
>
>>The Protocol ID block is only a byte long if I remember right.  Not
>>much savings to be had there.  No, and you absolutely need it to tell
>>AX.25 what level 3 protocol it is carrying.
>>
>>The information block won't change.  If you have any added data outside
>>the IP frame, it will be hard to get rid of the Frame Check block without
>>incurring corrupted data frames.
>>
>>It would seem that what you are proposing would be somewhat akin to a
>>proposal to get rid of the Ethernet Layer2 data on an ethernet connection
>>and just transmit the IP frames natively with only an originating MAC
>>address attached.
>>    
>>
>
>It would seem so.  How could this be accomplished this in a broadcast
>medium?
>
>  
>
>>It may work on an ethernet segment with a very limited number of nodes
>>but it isn't very scalable.
>>
>>I don't want to be a wet blanket on your idea.  Am I missing something?
>>    
>>
>
>I'm not sure how Maiko would accomplish what he is proposing.  The only
>place I have ever seen raw IP transmitted is over point-to-point (like
>serial) links where no "device" (i.e. MAC) addressing is necessary since
>the "device" at the other end of the point-to-point link hears all the
>frames on the link which are, by definition, "addressed" to it.
>
>["George (Skip) VerDuin" <k8rra at ameritech.net> wrote]:
>
>  
>
>>Throughout this process "overhead" remains a major issue with slow
>>speeds in some sectors of our hobby.
>>    
>>
>
>The "overhead" to which you refer is the "high-level" part the AX.25
>layer 2 implementation or LAPB.  LAPB requires an acknowledgement at
>layer 2 over the link and it is this that causes the large overhead.
>Normally, the payload "acknowledgement" function is reserved to
>transport layer 4 which is where is properly provided but the
>assumption is that you have a very reliable transmission medium
>(physical layer 1).  Unfortunately, our RF links provide a very
>UNreliable layer 1.  :(
>
>  
>
>>Recently, the address has grown from 32 to 64 bits and we can now
>>address more than whole earth.
>>    
>>
>
>We can practically address more than the whole earth with 32 bits too.
>Oh well.  Don't get me started on IPv4.  :)
>
>  
>
>>the more important concept is that KISS passes decision making
>>from the TNC to the data processing computer.  KISS (etc) is a
>>slick marketing tool to allow multiple application environments
>>for one hardware.
>>    
>>
>
>Perhaps, but it was not originally created to provide a marketing
>tool and it was never really meant to be "slick".  KISS (as implemented
>in TNCs and invented by K3MC in the late 1980s) was provided as a way
>to move the AX.25 (or MAC, "low-level") address part of layer 2 into
>the computer so that it could be configured on demand by users with
>changing callsigns/SSIDs etc.  This left only the physical interface
>between the medium (RF layer 1) and the computer to be handled by the
>TNC (or PAD).  PAD stands for "packet assembler/disassembler" and
>some of may remember when TNCs were called PADs.  :)  The simplicity
>of KISS for its day was awesome and to the best of my knowledge, the
>original KISS spec has not been changed although I may be quite behind
>the times on that one.  No doubt it has been expanded in some way
>since then.
>
>["Duvall [US], Mike J." <michael.duvall at sperry.ngc.com> wrote]:
>
>  
>
>>I had a similar thought years ago. It always seemed like a waste to
>>wrap x25 around and IP packet.  Legally all you need is the call sign
>>to identify the transmitting station.  A simple way to implement it
>>would be to prefix the IP packet with the transmitting station, SSID
>>and a check sum.
>>    
>>
>
>Yes, and that is called "AX.25".  :)
>
>  
>
>>You just strip these off on receive and pass the remaining data that
>>is IP packet on for processing.  In a more abstract sense, prefix any
>>network packet with the transmitting station, SID and a check sum.
>>    
>>
>
>Both of the above are exactly what AX.25 does now.  :)
>
>Ok, here's my take.  AX.25 in an of itself does not necessarily
>create more overhead (unless you are trying to use lots of digipeaters).
>In fact with no digipeaters and counting the SSID the AX.25 "address"
>is only one more byte (7) than is an ethernet MAC "address" (6).  And
>as Tim said above, the only added baggage is the control field (one byte)
>to bridge the gap between "low- and high-level" layer 2 because you STILL
>need a protocol ID field to tell AX.25 what it is carrying (even if it
>is plaintext and there are no higher layers).  Re-displaying Tim's model
>above, we see:
>
>Implemented by the PAD (KISS):
>
>	Start Flag
>
>Implemented by AX.25:
>
>	Address block (source, destination, 2 digipeaters)
>	("low-level" MAC data link layer 2)
>
> 	Control block (type of frame, sequence nbrs, etc.)
>	(bridge to "high-level" LAPB data link layer 2)
>
>	Protocol ID block (tcp/ip, net/rom, flexnet, etc.)
>	(bridge to network layer 3 or above)
>
>Implemented by network layer 3 and above:
>
>	Information block
>	(payload)
>
>Implemented by the PAD (KISS)
>
>	HDLC Frame Check block
>	End Flag
>
>So what then CAN be "corrected" with AX.25?  In my opinion, there is
>really only one item and that is, the need to make our RF circuits
>more reliable so that the requirement for using "high-level" layer 2,
>or LAPB will be eliminated.  If we did not need to use LAPB under most
>circumstances, this would do more to help our IP throughput problems
>over RF much more than eliminating AX.25 entirely would do.
>
>Just my 2 cents on this discussion.  :)
>
>73, de Barry, K2MF >>
>           o
>          <|>      Barry Siegfried
>+---------/-\---------------------------+
>| Internet | bgs at mfnos.net              |
>| HomePage | http://www.mfnos.net/~bgs  |
>+----------+----------------------------+
>| Amprnet  | k2mf at nnj.k2mf.ampr.org     |
>| PBBS     | k2mf at k2ge.#cnj.nj.usa.noam |
>+----------+----------------------------+
>
>_______________________________________________
>nos-bbs mailing list
>nos-bbs at lists.tapr.org
>https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs
>
>
>
>  
>