The IP Over NBMA (ION) Archive

[shur@arch4.ho.att.com]

Folks,

> From nexen.com!owner-ion@caig1.att.att.com  Mon Jul  8 10:58:39 1996
> 
> Bert,
> 
> > If we have a large cloud, though, with many egress routers wanting that 
> > multicast message, why would NHRP not cause a situation in which _all_ 
> > egress routers get their multicast from the one R1 ingress router? This 
> > might not be optimal. Would NHRP know to set up a nice tree structure 
> > within the cloud? Would other ingress routers be found, for instance, to 
> > create shorter paths between the actual source of the multicast and the 
> > destinations?
> 
> A possible way of setting up multicast shortcuts (with NHRP) is described in
> draft-ietf-rolc-pim-atm-00.txt.  It doesn't claim to solve all
> the cases of IP multicast over large ATM cloud, but it may solve 
> at least some of them.
> 
> Yakov.
> 

The argument/debate seems to be:

1) There exist some problems (e.g. IP multicast over a large ATM cloud
where the size of the multicast groups is very large), where
straightforward use of NHRP causes an excessive amount of signaling
messages to be processed/generated by senders to that group. Some people
have concluded from this that NHRP is not useful.

2) Another view is that there exist a number of problems (e.g., unicast
cut-through, IP multicast over small multicast groups per above draft)
where NHRP provides useful solutions. Other people have concluded from this
that NHRP is useful. 

I support the second view. There are many important services (e.g., Web based
Multimedia on Demand, Multimedia Conferencing) which fall into the second
category. Any technology that helps solve these problems, even if it
does not solve all problems, is useful.

David Shur.