The IP over ATM Mailing List Archive by date

[Curtis Villamizar <curtis@ans.net>]

In message <199504172359.TAA17804@thumper.bellcore.com>, Grenville Armitage wri
tes:
> 
> Two problem cases were raised - that of the IP host attached to a
> cluster, and that of the IP multicast router sending into a cluster.
> The answer that I should have given, and which will be explicitly
> noted in ipmc-05, is as follows:
> 
> 	- ip/atm interfaces must (after demuxing on the LLC/SNAP
> 	  header) compare the IP src address in the packet
	  with the local hosts own IP address(es). If it matches,
> 	  the packet is dropped.

The source address may not be the senders address.  IP multicast gets
forwarded by multicast routers.  Certain multicast routing algorithms
(shared trees) do not support multicast routes on a per source basis,
but rather on a per interface basis.  An action item from the meeting
was to determine if CBT and PIM Sparse could accept this limitation.
The preliminary guess was that CBT couldn't and PIM might.  I thought
it was agreed to bring this up with the IDMR WG for an authoritative
confirmation.

> 	- IP multicast routers automatically filter such returned
> 	  packets, as the forwarding engine will detect (based on
> 	  the IP src address in the packet) that it should not have
> 	  _arrived_ on that interface.

This may not be true for shared trees which don't route based on IP
source, but rather on previous interface.  If you've confirmed this
with IDMR, then I appologize for bringing it up again.

> The first rule covers an IPmc router that is also a host sending to
> a group. It is also worth noting that the first rule is not a change
> to the IP layer, but a function of the IP/ATM interface/driver in
> your operating system.
> 
> cheers,
> gja
> ---
> Grenville Armitage, Research Scientist,      MRE 2P-340, 445 South Street
> Internetworking Research Group, Bellcore.      Morristown, NJ, 07960, USA
> (email) gja@thumper.bellcore.com  (voice) +1 201 829 2635 {.. 2504 (fax)}

Curtis