The IP over ATM Mailing List Archive by date

[Grenville Armitage <gja@thumper.bellcore.com>]

At the Danvers IETF I put up slides noting that ipmc-04
was designed to help manage two types of link-level
multicasting mechanisms - meshes of point to multipoint
VCs, or centralised ATM level multicast servers. ipmc-04
allows this choice to be made on a per IPmc group basis,
in a manner transparent to the hosts in a MARS Cluster.

A question was raised as to how IP sources handled seeing
their own packets coming back when they transmit to an IPmc
group that is supported by an mc server.

This is a reasonable question which ipmc-04 does not answer
as explicitly as it could have. Appendix C merely notes that
sources must either deal with the problem or use VC meshes.

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.

	- 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.

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)}