Linux-ATM support.

[Lamar Owen]

On Saturday 31 July 2004 13:51, Charles R. Anderson wrote:
> On Sat, Jul 31, 2004 at 12:46:53PM -0400, Lamar Owen wrote:
> > So ATM features are more Enterprise than hobbyist, but having robust ATM
> > networking for CLIP over PVC and SVC as well as LANE support could raise
> > some interest in high-bandwidth applications.

> ATM is still too overly complex as an Enterprise networking
> technology.  Certainly support should be there for those who need it,
> but I doubt it is worth the effort just for new high-bandwidth
> applications, unless the intent is to work with legacy ATM
> infrastructure.

But all telco infrastructure on the WAN side is SONET, and most is ATM.

> Ethernet can do that with 802.1Q VLANs.  I just don't see the
> advantage of ATM for new deployments in this case.

Real traffic isolation at the link level.  Since ATM is connection-oriented, 
there are no broadcasts to sniff, no way for a random user to get any traffic 
they aren't supposed to see.

There are a few reasons I picked ATM over gigabit Ethernet.  The first one was 
distance.  My fiber runs average longer than 300 meters, which is the limit 
for 1000Base-SX on my fiber (which is already installed, and relatively old 
at this point, having been installed in the early to mid 90's.  I have more 
than one run of fiber that I am using that is longer than 600 meters, but 
works fine with OC-12 over multimode (HP HFBR 5208 transcievers)).  
1000Base-LX is too expensive.

I have $2,500 invested in my ATM LAN with OC-12 links.  Server connections are 
available with 1000Base-SX and OC-12 ports.  The switches feature full 
hot-swap redundant power supplies, hot-swap interface cards, and enterprise 
SNMP management.

Can 802.1Q give me full, automatic, link failover at the link level?  With 
automatic load balancing?  The PNNI implementation in the 3Com gear does 
both, transparently to the AAL5 above.

> Emulating 
> broadcast LANs on top of circuit-switched technology is inefficient,
> complex, and fragile.  On the other hand, the support could be useful
> for those stuck with legacy ATM in order to create firewalls, IDS's,
> flow analysis tools, etc.

Yes, LANE is not the most elegant solution ever invented. But once the VCC is 
up, the throughout is very good, and competive to CLIP.  As far as 'legacy' 
goes, ATM is at the core of new technology, not just old.  ADSL, for 
instance, is ATM.  To support some USB ADSL modems requires the ATM stack; in 
particular, PPPoA on the Alcatel Speedtouch is in kernel-2.6, but not built 
in the Fedora kernel by default.

> Ugh.  It seems silly to create all that complexity just to work around
> the inherent weaknesses of the LANE technology, with all the overhead
> to boot.  I don't think you characterize the average IT person.

No, I don't, I guess.  3Com's Transcend Enterprise Manager did all the heavy 
lifting.  I just had to think through what I wanted, and learn the 
terminology, and characterize the topology desired.  PNNI on those switches 
isn't hard, once you wrap your mind around it, remembering that ATM is 
circuit-switched technology.  And you don't have to do anything at the IP 
level; it's all handled transparently to the IP layer.

I have yet to find an affordable gigabit layer 3 switch that can do now what 
this ATM gear could do in 1998.  Automatic load balancing and failover were 
and are dealbreakers for me, given the geographic issues on my campus.  Now, 
these ATM switches were not really affordable in their day; but they are 
_now_, and on an educational budget they work wonderfully well.

> > And it impresses people to no end when I physically pull an OC-12
> > trunk fiber out of a switch port and the switch transparently
> > reroutes over the other fibers....

> Ethernet can do that too with 802.3ad Link Aggregation.  I too went
> through my ATM phase and I'm much happier now that I have migrated to
> a completely Ethernet infrastructure.

I had a couple of Bay Networks switches that did the aggregation and trunking.  
It was not as smooth nor as fast.  Since implementing the ATM LAN things are 
much smoother here. YMMV, of course.  ATM is not the be all end all, but 
neither is Ethernet.  Nor is TCP/IP for that matter.

However, ATM is still very popular, in particular for the home user who wants 
to use Linux and a USB ADSL modem that implements PPPoA (Alcatel Speedtouch, 
for instance).  This is not uncommon, and can provide lower latency and 
higher throughput than PPPoE.  I know a number of users on my ISP that run 
the Speedtouch on Windows; they can't switch to Linux unless the PPPoA 
support is there.

But the biggest reason I like and use ATM is the fact that there is no 
boundary between WAN and LAN, since ATM is mostly a WAN technology.  And I am 
going to be using a Linux ATM firewall when I get a bigger pipe out of here.  
The usage to which I am going to put my facility also make ATM attractive; I 
want to be able to park a cage in a building and give users their own PVC's 
in that are invisible to other users here, even though they are carried by 
the same fiber and the same switches.

But our goal here is an OC-48 incoming for real-time telescope control; not 
the typical application, granted.

My new ATM-enabled kernel is up and running on FC2, now.  Only took 90 minutes 
to rebuild the RPMs on a 2.4GHz Xeon (!!!???).  Now to test my cloud's 
bandwidth.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu