The IP Over NBMA (ION) Archive

[Albert Manfredi <manfredi@arl.bna.boeing.com>]

Telford001@aol.com wrote:
> 
> In a message dated 96-12-10 06:20:14 EST, magician@kuis.kyoto-u.ac.jp
> (FUJIKAWA Kenji/=?ISO-2022-JP?B?GyRCRiNAbjgtPCMbKEI=?= ) writes:
> 
> > ATM does not need to have multipoint-to-multipoint connections.
> >  In the desirable multicast mechanism,
> >  a sender need not to know the receivers,
> >  a recceiver need not to know the senders,
> >  all each has to know is the multicast group address
> 
> Agreed.  Emulating IEEE broadcast and multicast capabilities
> in my LAN switch was trivial.  There is no reason that providing
> such emulation should not be trivial in ATM switch.

I don't know. This talk of "trivial" makes me very nervous, assuming I
understand what people are saying here.

The fundamental problem with many-to-many is a problem that exists
irrespective of ATM or other scheme. It is a problem of merging flows at
the receivers, while pretending to maintain some semblance of QoS.

ATM simply makes this problem crystal clear, by wanting one to set up
one VC per sender, at each receiver. If you can't hack the number of VCs
you need, then what makes you think you have enough bandwidth? Now sure,
you can play games with a VC for multiple IP connections, but now you're
simply throwing ATM away. You might as well use fast Ethernet and accept
that bandwidth limitations will degrade quality.

> One
> would think that at least one of the ATM switch vendors would
> add such a valuable extension if only to create a marketing
> distinction among its ATM switch and ATM switches from
> other vendors.

This extension is mostly valuable for marketing purposes only, though. I
guess that's important too, but don't you wonder why bother?

Bert
manfredi@arl.bna.boeing.com