Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 May 1997 23:56:22 -0400
From:      "Louis A. Mamakos" <louie@TransSys.COM>
To:        Chuck Robey <chuckr@glue.umd.edu>
Cc:        Mark Tinguely <tinguely@plains.nodak.edu>, black@zen.cypher.net, sthaug@nethelp.no, hackers@FreeBSD.ORG
Subject:   Re: Why use ATM, (was Cluster Computing in BSD) 
Message-ID:  <199705170356.XAA12741@whizzo.transsys.com>
In-Reply-To: Your message of "Fri, 16 May 1997 17:27:36 EDT." <Pine.BSF.3.91.970516171733.7298E-100000@Journey2.mat.net> 
References:  <Pine.BSF.3.91.970516171733.7298E-100000@Journey2.mat.net> 

next in thread | previous in thread | raw e-mail | index | archive | help

> You say that ATM is losing out to ip and (perhaps) to Sonet.  This is 
> juggling the protocol levels badly in my mind, because SONET is a link 
> level protocol (so it isn't encapsulateable by anything), while ATM 
> isn't, it needs a link level protocol to ride on.  What I'm saying, is I 
> don't think that ATM can be in competition with SONET; that's why your 
> statement confuses me.

I think that the comparison is between running IP as packets framed in
a SONET payload as compared with running IP sliced/diced into ATM cells
which are transported in a SONET payload.

In both cases, you're using SONET framing and transmission.  The like
comparison is running IP in PPP on DS3 framed in HDLC as compared to
IP in ATM "classical IP" on DS3.

Why is this significant?  I ponder this question in my "day job" doing
network architecture and strategic technology planning for a large
ISP.  (Do a traceroute, and I'm sure you'll be able to tell which :-)
There are two advantages to using variable-length packet over SONET
compared to ATM over SONET:

1.  The cell tax.  The economics of the Internet business are pretty
easy to understand; the predominant recurring costs are for long-haul
transmission facilities; being at a 10% or 15% disadvantage in utilization
of these expensive and scarce resources is significant and visible on
the bottome line.

2.  Implementation effort.  Consider the end-station (host or router).  Do
think it's going to be easier to build an OC-48c (2.5Gb/s) SAR devices, or
an OC-48c HDLC framer?  How much fiendishly expensive statis SRAM will
you need on the OC-48c ATM interface for packet reassembly buffers.  (Before
you can answer that question, you need to know how many VCs the interface
needs to handle).  

If you're only doing IP (and its not like most Internet networks have all 
this excess capacity available to be shared for other services), why
slice/dice/reassemble?  

There will be OC48 routers and switches next year, that run multiple 
wire-speed ports at OC48 rates.  If not, then we're all in a world of
hurt given the growth rates of the Internet.  The thing that makes ATM
switches go fast isn't the fixed 53 byte packet size; its the short
address in a fixed location it routes/switches on.  You can observe
that Frame Relay, for instance, shares this characteristic using variable
length frames.

> On top of that, I thought that ATM was being used as a way to link LANs, 
> so ip would be routed over ATM links, and again, not competitive.  You 
> could conceivably have a SONET link that had an ATM constituent, which 
> was carrying an ip message inside it.  That's the way I understood it, 
> and that example was (supposedly) fairly common, at least as common as 
> SONET itself is.
> 
> Where am I wrong?

SONET framing is the linga franca of the optical transmission world, and
gets used for lots of stuff.  The vast majority of it (in miles, anyway)
isn't ATM, but TDM payloads (usually 45Mb/s DS3 circuits) carried as
payload, having been muxed up.

In the LAN market, it's going to be real hard to understand why 100Base-T
isn't going to display ATM to the desktop, and perhaps gigabit ethernet
displaing ATM in the LAN "trunking" application.  There are some nifty
things you can do with ATM if you can afford to pay the overhad (both
bandwidth and implementation costs), but it's going to be application
specific.

louie





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705170356.XAA12741>