www.a00.de > tcpgroup > 1994 > msg00032
 

TCP-group 1994


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Should we share?



> 
> 
> > AX.25 routing?  Gag me, Witherspoon!  It is like building large
> > extended LANs.  I sort of make a living now helping clients dig 
> > themselves out of that hole.
> 
>  LAM> But you can also look at the AX.25 level-2 fabric as a switching
>  LAM> facility, much the same way that you use Frame Relay to carry IP and
>  LAM> other protocols.  If you can, somehow, use it to connect together
>  LAM> different radio subnets into one larger, logical subnetwork, then it
>  LAM> could actually win.  Maybe.
> 
> That's like saying that one could, in theory, move the Atlantic Ocean to the
> Pacific Ocean using succesive operations involving a teaspoon.  AX.25 has no
> switching facilities in it except for really awful half-baked approximations 
> such as digipeating.  There have been attempts to squish such features on top
> of AX.25, most notably netrom, but running IP over netrom is much like
> subjecting the teaspoon hypothesis to empirical testing.
> 
> Fred is right on this one, as he has been for years.  What we really need is a
> dynamic IP routing protocol that does not assume the existence of reliably
> connected subnetworks, since we don't have them.  The other major exponent of a
> solution to this longstanding issue is, in my opinion, Glenn Elmore, who has
> been reminding us at frequent intervals for the past several years that the
> real problem with packet is lack of attention to the physical layer.

But consider the concept, rather than the current implementation.

Having a communications subnet running below IP which could span
multiple frequencies, modem technologies and access methods and have
it appear as a logical "subnet" to IP might be a good thing.  

This is what Frame Relay is today - level 2 switches running their own
routing protocol that give IP the appearance of a multiple access
network.  And ATM.

The ARPANET was also built like this, with IMPs, er, PSNs acting as
level-2 switches, carrying multiple protocols above it.

This approach also has some desirable properties in that instability
in the level-2 fabric need not preturb the IP routing system.  On the
Internet today, this would would be a good thing.  The routing "flux"
is rather high these days..  

There may be good reasons to seperate this out - consider the future,
where you have multiple applications competing for bandwidth.  You
could logically define multple communication subnets over the same
medium, and have different bandwidth available to each one.  Assuming
the fabric was smart enough, you can reserve some minimal amount of
bandwidth for each logical comm subnet - sort of like a Frame Relay
CIR.

This is just what you have today on your ethernet if you're bridging
segments together.  IP (or DECnet or IPX, etc) are completely unaware
of the Spanning Tree algorthm running in the bridges which are the
fabric of the Ethernet LAN.

This sort of "packet radio fabric" implementation might be what's in
the 'TNC' of tomorrow, which presents some generic interface to the
actual nodes on the net.

I think that this was what Brian was getting at in his comments a few
days ago.

We ought to be open to new ideas; ham radio is infamous for taking
just-now-working technology, declaring it a standard, and shipping it
to the masses before being able to develop a *good* solution, rather
than a *working* in the lab sort of solution.  (Bell 202 modems,
AX.25) Just because it works for 1, 10 or 100 doesn't mean it scales
well to 10000.

Louis A. Mamakos, WA3YMH                      louie@alter.net
Backbone Architecture & Engineering Guy       uunet!louie
AlterNet / UUNET Technologies, Inc.
3110 Fairview Park Drive., Suite 570          Voice: +1 703 204 8023
Falls Church, Va 22042                        Fax:   +1 703 204 8001





Document URL : http://www.a00.de/tcpgroup/1994/msg00032.php
Ralf D. Kloth, Ludwigsburg, DE (QRQ.software). < hostmaster at a00.de > [don't send spam]
Created 2004-10-04. Last modified 2004-10-04. Your visit 2021-10-24 05:12.45. Page created in 0.0185 sec.
 
[Go to the top of this page]   [... to the index page]