Cell Relay Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Re: Forwarding between ELANS in LANE 2.0 & LANE frame format
In article <866ieq$lm8$1@nnrp1.deja.com>, mredondo@idecnet.com wrote: > 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. Any time you do IP over ATM, you will hide some of the benefits of ATM. In part, because IP can't use the QoS and CoS features of ATM very well. And voice over IP requires a lot of overhead. So if you start doing voice over IP, and then layer that on top of IP over LANE over ATM, you are adding insult to injury. LANE has two encapsulation options, which add either 16 or 28 bytes of overhead per frame. AAL5 adds another 8 bytes of overhead. So total overhead per frame is the 48/53 cell overhead + 24 bytes or 36 bytes, depending on encapsualtion option. But with Ethernet, the overhead is 26 bytes or 34 bytes per frame, depending whether you use the type or the length format. So if you can pack one or two cells efficiently for a voice packet, ATM is still a reasonable choice, even for voice over IP over LANE over ATM. Voice over native ATM, using either pt-mpt SVCs or UNI 4.0 multicasting, for one-to-many voice channels, is not a bad way to go, assuming you have ATM end users. In my opinion, with any speed advantage ATM had no longer being a factor, if you have only IP transport to consider, ATM is a hard sell. -- Bert albert.e.manfredi@boeing.com Sent via Deja.com http://www.deja.com/ Before you buy.
|
|