Q:Why router with ATM interface comes out earlier than pure SONET interface?

Christian Kuhtz ck at bellsouth.net
Mon Aug 3 16:01:02 UTC 1998

>   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.


Christian Kuhtz, BellSouth Corp., Sr. Network Architect  <ck at bellsouth.net>
1100 Ashwood Parkway, Atlanta, GA 30338                        <ck at gnu.org>
"Turnaucka's Law: The attention span of a computer is only as long as its
 electrical cord."                                    -- /usr/games/fortune

More information about the NANOG mailing list