The IP Over NBMA (ION) Archive

[Curtis Villamizar <curtis@ans.net>]

In message <31F6DAF4.841@engr05.comsys.rockwell.com>, Albert Manfredi writes:
> I think that draft-armitage-ion-venus-00.txt pretty thoroughly covers the 
> problems of cut-through multicast over unrestricted size ATM nets. The 
> issues are analyzed at the microscopic level, convincingly so, but less 
> microscopic investigation would have come up with the same conclusion.
> 
> In general, all multicast models that work aggregate at different levels. 
> This is true for "broadcast" radio and TV as it is for IP mrouters. So if 
> we have an ATM network that spans the globe, there is no reason to 
> believe that reasonable multicast can possibly be supported without the 
> same sort of aggregation.
> 
> One solution is to say that at a certain point, we can't do pt-mpt VCs 
> where the source must be aware of and maintain a list of all active 
> participants, and must therefore resort to mrouters. To me, this is 
> avoiding the issue "But how would a global ATM do this?" I don't believe 
> the answer is "The global ATM must use IP multicast solutions."
>  
> Or if it is, then we've again given up on making use of this different 
> technology's potential benefits.
>  
> The answer has to lie in using ATM's own aggregation capabilities, in its 
> own topology. Assume that ATM is flat, and that type of solution will 
> never happen.
> 
> Not a job for the IETF? True. It's a job for the ATMF, and hopefully the 
> IETF would make use of those solutions.
> 
> Bert
> manfredi@engr05.comsys.rockwell.com


Bert,

If we want solutions this century, the IETF needs to pursue a means to
do multicast given currently defined ATM standards, and even using
currently implemented ones.

Most carriers that offer ATM at all don't even offer SVCs let alone
pt-mpt with receiver initiated join or some yet to be defined scalable
solution you elude to above.

Curtis