[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    (IPng 4969) Re: IPv6 over ATM encapsulation
From:       Albert Manfredi <manfredi () arl ! bna ! boeing ! com>
Date:       1997-11-24 21:13:56
[Download RAW message or body]

Placed in order of importance,

Christian Huitema wrote:

> In any case, this discussion has only a minimal relation to the design and
> implementation of IPv6.

True enough.

> > The problem here is one of semantics in marketing, not real world.
> > To keep the playing field even, OC-3-based ATM should always have
> > been called "135 Mb/s." Alternatively, 10 Mb/s Ethernet should
> > always have been called 20Base-whatever, and FDDI should have been
> > called 125 Mb/s.
> 
> Uh? the "cell tax" argument usually refer to the comparison of two well
> defined stacks, IP>PPP>Sonet and IP>PPP>ATM>Sonet.  A classic case of
> whether the overhead (cell) is worth the functionality (switching).
>  Opinions are known to vary.

Right, Christian. I know.

Let's look at the complete overhead picture, IP over Manchester, IP
over FDDI (4B/5B), and IP over ATM/SONET.

IP over Manchester = 50 percent overhead, + Ethernet + IP overhead.
Manchester requires two clocks per data bit.

IP over FDDI = 20 percent overhead, + FDDI + LLC + IP overhead.
4B/5B requires frive clocks for 4 data bits.

IP over ATM/SONET at OC-3 = 12.8 percent overhead + LLC + IP
overhead. ATM and SONET use scrambling to ensure a low DC content,
rather than extra clocks.

Even if you point just to the ACK frames, compared with Manchester,
ATM does better.

Bert
manfredi@arl.bna.boeing.com

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]