This issue is precipitously close to a religious issue, but hopefully we can forego the fall.
:)
One of the nifty things about ATM is that cells are of the same size, so building physical interfaces is a bit easier, as the timing is deterministic.
.. and ASICs have been in development longer, and which much larger financial backing (all the PTTs of the world etc).
One of the drawbacks of ATM is that to run IP/ATM we have to do SAR [Segmentation and Reassembly]. Another drawback is the overhead of ATM, arguably somewhere between 5-30%, but inarguably greater than native IP/sonet.
What, you seem something wrong with SAR'ing all over the place? *tongue firmly planted in cheek*
Notwithstanding these two significant technical issues, market maturity and interest also impacts this significantly.
Look at it this way.. how many service providers are there... how many enterprise customers are there... well, which technology used in which market will get the most beating up and innovation? Yes, there are a lot of things in enterprise that do _not_ work in service provider applications. However, the differences that I have seen in terms of demands from service providers are usually centered around greater flexibility, higher scalability and more distributed control (much like very large enterprise customers). And then there are the few unique needs of service providers which rarely ever show up in enterprise -- like the rather unique buzzing over L2TP etc.
Recently the market seems to be growing more towards 'convergence' at the IP layer, with the predominant audience of applications using native IP, be that over VPN or the greater Internet.
Well, that, and then you see all the applications in the corporate world, all of them built on IP. Not on ATM. What do you think is going to drive innovations and requirements on the service provider side? Service providers aren't just here because somebody thought it was cool to have service providers. And if a service provider uses fundamentally different technologies and approaches to solving the problem of the customers in an attempt to generate revenue, the service provider better be running similiar technology (like the customer). Otherwise it'll hardly be efficient. If someone has a different opinion, I hereby invite you to make a counterpoint and prove me wrong.
In addition to that, we should consider traffic engineering and the motivations of a 'large' NSP/ISP to build a scalable efficient architecture.
.. which is where all the fun n^2 issue which seem to be afflicting all ATM network come in.
Recently, due to good theoretical work, and practical demonstrations by vendors, MPLS has emerged as a viable competitor for ATM in the field of traffic engineering.
Yep. Even thought the ATM vendors try to tell you that MPLS is playing in their backyard (Ascend to mention just one of them) and that it justifies building an ATM core. One of these days someone will get the idea that MPLS is intended to be connectionless. The connectionless way of looking at the world makes sense in an IP world. It doesn't make much sense to folks who have done circuit switching for their entire lives (or most of it). I just hope that the awakening doesn't come at too high of a price to the latter.
I believe these variables contribute to the history of ATM as a fore-runner [2], and the emergence of Packet over Sonet as the leading ubiquitous transport platform for the communications network of the world.
It will be quite interesting to see who is first-to-production with OC-48.
My money's on Packet/Sonet.
Albeit I agree, it depends also on how much money you're willing to blow to sustain a dream/vision/crazy thought.. "first in production" may be a dubious measure. We usually assume 25% cell shredder tax on ATM vs. POS. At OC-48, you'll be blowing an OC-12 in framing. Seems like an awful waste of bandwidth to me. Cheers, Chris -- Christian Kuhtz, BellSouth Corp., Sr. Network Architect <ck@bellsouth.net> 1100 Ashwood Parkway, Atlanta, GA 30338 <ck@gnu.org> "Turnaucka's Law: The attention span of a computer is only as long as its electrical cord." -- /usr/games/fortune