Subject: [Ipoverib] remaining multicast issues - one more try

From: "H.K. Jerry Chu" <[email-masked]>
Date: Fri, 31 May 2002 20:05:42 -0700 (PDT)

A couple of weeks ago I asked IBTA for a summary to the IPoIB
reflector on the changes likely to come as part of IBA 1.1
spec later this year that will affect IPoIB. Unfortunately,
the request was declined because IBTA rules forbid any 1.1
info to go outside of member companies at this point. But
based on my knowledge of their progress I felt comfortable to
move the current drafts forward without risking incompatibility
with IBA 1.1. If the latter does happen, we can always amend
the drafts then.

But yesterday I heard from David Brean of IBTA/MGTWG that the
item 3

a facility to allow the software emulation of the promiscuous
multicast mode

remains unresolved within IBTA. Vivek also raised some concern
too. IMO it is probably not worth holding the drafts for a single
issue. But I decided to give it another try to resolve this issue
in the next few days. If we can't reach a consensus before next
Friday, I'd suggest we move the rest of the drafts forward
leaving this issue behind to be addressed later.

Let me restate that the promiscuous multicast mode is not only
required for the proper operation of IP group mamagement protocol,
it is also how a sender's multicast pkt gets picked up by an IP
multicast router. The details are described in

rfc1112 -
"Note that the multicast routers receive all IP multicast
datagrams, and therefore need not be addressed explicitly..."

rfc2710 -
"For each interface over which the router is operating the MLD
protocol, the router must configure that interface to listen to all
link-layer multicast address that can be generated by IPv6
multicasts..."

IBA 1.0 spec. does not provide a promiscuous multicast mode in
hardware or allow one to be emulated in software. So far there
have been three proposals to address this issue:

1. Require the IPoIB driver to send a copy of every outgoing
multicast pkt to the all router multicast group. The algorithm
looks like this: for a pkt destined to a multicast group M

	if (M doesn't exist)
		send pkt to all_router
	else if (M != all_router)
		send pkt to all_router;
		send pkt to M;
	else send pkt to M;
		
2. Modify IP group management protocol module to do some extra
work in case the link type is IB. An IP router will explicitly
join any new multicast group that comes into existence. The
router needs to figure out when to leave too (details from
Vivek).

3. Ask IBTA to add a facility to allow promiscuous multicast
mode to be emulated in software.

1. above seems to be the least painful. But it requires every
node to be capable of sending pkts to all_router multicast
group.

The biggest problem with 2. IMO is that it requires changes to
existing IP code in every version of group management code
including IGMPv1, IGMPv2, MLD..., etc, and the change doesn't
seem trivial. It may present a big obstacle for many OSes to
request IB only changes in generic IP code.

From what I've heard 3 should be simple to add. The SA has all
the MC info already. It simply needs to supply the caller a
list of all the existing MC groups, and notify the caller of
any new group coming into existence so that the caller (driver
of an IP router) can ensure it "join to observe" every
multicast group.

Please express your opinion if you have one in the next few
days. If we can't get to a consensus I'd say we shelf it and
proceed with the rest of stuff. Note that since the
encapsulation draft has a dependency on the link/multicast
draft, it can't move forward alone. Also I don't want to wait
until September for the IBA 1.1 spec. We have other work to do.

Jerry

_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib