Cell Relay Archive

[mredondo@idecnet.com]

Thanks Albert.

> > > With LANE, you need a router to go to other Layer 3 networks (e.g.
> to
> > > reach another IP subnet). Or a bridge to go to other segments of
> that
> > > same Layer 2 network (e.g. LANE and an Ethernet segment are both
in
> > the
> > > same IP subnet).
> >
> > What do you mean with Layer 2 network?
> > Maybe an Ethernet MAC (LEC client) member of the same ELAN?
>
> No, I mean that your local IP subnet _could_, in principle, consist of
> several Ethernet hosts connected together via Ethernet hubs _and_
> several LANE hosts using the Ethernet framing option of LANE
> (preferably), connected together by an ATM mesh. And the ATM and
> Ethernet LANs, which form a single Layer 2 network, would be tied
> together with a bridge (or two or three or more).
>
> As you can see, this would be a single Layer 2 network, because two
> stations communicating to each other in such a network would never
need
> to cross a router. The IP net ID is the same for these two stations.
> Yet, one might be Ethernet and the other ATM LANE.

Ok, I see. But I think for large networks the broadcast would be too
high because bridges don´t stop broadcasts. Every broadcast sent would
reach all of the hosts of all the layer 2 networks. In my opinion this
doesn´t scale.

> > > > How many bytes do you have add (AAL5,LANE,...) to the ethernet
> frame
> > > to
> > > > have a packet ready to be cut in cells of 53 bytes?
> > >
> > > Don't worry about it. SAR (segmentation and reassembly) worries
> about
> > > packing cells correctly. It happens in the ATM NIC, all by itself.
> >
> > Maybe I didn´t explain well. I just wanted to know how many bytes
are
> > added by LANE and AAL5 to the Ethernet frame (Overhead). Just to
know
> > the different bandwidth used in the Ethernet and ATM link.
>
> The difference in overhead caused by packet framing, for full-speed
> transfers like FTP, will be small. You can count up the bytes if you
> want, by downloading the LANE Spec at www.atmforum.com, in the
approved
> specs folder. The bigger cause for overhead will be the cells
> themselves, though, which basically amounts to 48 payload bytes for 53
> cell bytes.
>
> BUT, don't forget that you're comparing apples and oranges.
>
> When you say "100 Mb/s Ethernet" you are really saying 125 Mbaud
> Ethernet.
>
> When you say 155 Mb/s ATM, that refers to essentially a baud rate, not
> bit rate. So a 155 ATM net is actually 136 Mb/s system, if you want
the
> actual data rate to compare with Ethernet.
>
> Different conventions were used when identifying Ethernet and ATM
nets,
> so this whole overhead thing got blown out of proportion. In ATM, it's
> the actual symbol rate over the physical (SONET) layer.

Ok for that. But in multimedia applications such as voice, if your
ethernet hosts send for example compressed voice (G.729,G.723..) frames
of 20 bytes each, the overhead caused by Ethernet-LANE-AAL5-5bytesATM
starts to be really serious, and SAR also becomes a problem.

The reason for these questions is a research to develop a big (2000
hosts) multicasting Voice over IP network. We are finding that ATM is
perfect for Point-to-Point voice, but multicasting in LANE ATM starts
to be no so good. And if hosts are Ethernet, overhead and SAR´s can
hide part of the benefits of ATM.
The number of SVC´s when many hosts want to listen to one are also
becoming a problem.
MPOA works for long duration calls so the first frames are broadcasted.
ATM QoS is not the same as LANE QoS.
So we are also thinking about Gigabit Ethernet.

This is my opinion, and I´m sure some of them are wrong or they are not
all true. But I think if you are multicasting seriously, ATM is not the
right solution.

Thanks for your help.
Miguel Redondo


Sent via Deja.com http://www.deja.com/
Before you buy.