The IP over ATM Mailing List Archive by date

[Tony Ballardie <A.Ballardie@cs.ucl.ac.uk>]

I was forwarded a recent ip-atm posting since I'm not on the 
ip-atm list, but it was thought I might be able to offer some 
input here.
 
I was involved in an e-mail discussion shortly after Danvers
IETF when the problem re: IP-ATM m'cast servers reflecting
multicasts back to the source of those m'casts.
 
  > from Jim Foster's recent ip-atm posting:
  > 
  >  End System sourcing mcasts directly onto ATM.  When the echo comes back
  >  it's clearly trivial to look at the source IP address and discard the
  >  echos.
 
Agreed.
 
  >  Router forwarding mcasts.  It depends a bit on the multicast routing
  > protocol, but it turns out they all have mechanisms that can be used
  > straighforwardly to this:
 
PIM, DVMRP, MOSPF were all mentioned, which forward multicasts
based on source IP address. CBT does not. Any m'cast protocol involving
shared tree forwarding typically does not have the concept of "correct
arrival interface". Similarly, the IP source address is not used to
establish forwarding interfaces.
 
In the case of a m'cast forwarder, packets coming _in_ (being forwarded into
the local LIS by a router) will be reflected. For multicast protocols that
base their forwarding on src address this problem can be solved within
the forwarding engine. But, for those that don't forward based on IP src
address (shared tree schemes) this is a big problem, and at the moment I
don't see how this can be solved at the IP level.
 

Tony Ballardie (IDMR co-chair)