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

From: "H.K. Jerry Chu" <[email-masked]>
Date: Tue, 18 Jun 2002 16:19:01 -0700 (PDT)

Thanks for the explanation, Bill. So if I understand correctly,
proposal # 2 won't work unless changes are made to the IP code on
both the host side and the router side (with the exception of IGMPv3,
which has been widely deployed), right?

I proposed a "hack" (#1) initially to require the host side IPoIB driver
to copy every outbound multicast pkt to all-router. There was a small
problem if a router itself is a genuine member of the targe multicast
group but this problem can be worked around easily (yes more hack :-(.
This workaround is not something one would brag about. But at least
it is transparent to IP implementations.

A different proposal #2 below was made later (by Vivek). My problem
with that propsal is that it requires link-specific changes to router
implementation. Now it looks like it requires changes to host side
as well.

I have also tried to get IBTA to add support for a software emulation of
promiscuous mulicast mode (#3). From what I heard IBTA was close to
getting one done. But there seemed to be some misunderstanding leading
them to believing IETF has a solution already (which I don't believe
is the case), and a solution is no longer needed from them.

My personal opinion (WG co-chair hat off) is that if adding promiscuous
mode support is doable and does not negatively impact IBA architecture,
that solution is much preferred than the above two. And one never knows
if other protocol or any future ones will require promiscuous multicast
mode (albeit it is arguably a bad design). If others on the list agree
we should let the voice be heard by IBTA members.

BTW, which one of the three above do you prefer, Bill?

Jerry

>I removed a couple of round trips from the quoting here, in order
>to simplify the exchange.  Apologies if I misunderstood something and
>acidentally modified or misattributed someone's meaning.
>
>Jerry's original #2 suggestion:
>
>>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).
>
>
>Vivek replies:
>
>>        In existing implmementation the routing daemon on receiving an
>>        IGMP report adds the IP multicast group to the interface list.
>>        It tells the kernel to add the group by a socket option (in
>>        BSD/LInux implementations). The function after it adds the IP
>>        group to the interface can call the interface's device
>>        specific function - for IPoIB this function will ask the
>>        driver to join the IB group.
>
>How does the router receive the IGMP report?  In IGMPv1 and IGMPv2, the
>report is sent to the group being reported, with the assumption that the
>router, being promiscuous to multicast, will receive it.  IGMPv3 changes
>this to send to a protocol-specific "all-IGMPv3-routers" group, so doesn't
>have this problem in an IB environment, but IGMPv3 is not widely deployed.
>
>Existing router implementations of which I'm aware (mrouted/gated/pimd/etc)
>don't specifically add a group to an interface in the kernel; instead they
>wait for data to arrivate and add a forwarding cache entry for the given
>source and group.  The router implementations would have to be modified
>to inform the kernel of group memberships on a given interface.
>
>Modifying host implementations to send IGMP to the all-routers group
>could work, but that's back to modifying the IP stack for an IB-specific
>case.
>
>  Bill

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

---

From: Vivek Kashyap <[email-masked]>
Date: Tue, 18 Jun 2002 16:45:29 -0700 (PDT)

> which has been widely deployed), right?

        Read my previous mail - I have put forth this example earlier
        too. Let us discuss this in detail before knocking it off.

> it is transparent to IP implementations.

        As noted earlier in the thread - this has the possibility of
        inserting duplicates in the network. To implement the 'hack'
        wouldn't the router have to change too and the host too ?

	As was noted on June 7th in this thread:

            "How do one ensure that the router is not a member of any
            IB group ? What mechanism stops it from being a member ?
            Many nodes do double duty - they host applications and
            also act as routers - how do they decide?

            As per this solution a router will receive two packets and
            if the IP subnet has multiple routers then multiple
            routers get two packets. If the corresponding IP group has
            a scope larger than the local subnet - each of these
            routers will now forward multiple packets outward. If one
            or more of these neighbouring subnets are IPoIB subnets we
            can further multiply the number of copies by a factor of
            two at the least. The result would be that IPoIB
            subnetswould end up creating multicast storms quite
            often.  "

> implementation. Now it looks like it requires changes to host side

        Not later :) - I proposed it in my earliest drafts too since
        the IBTA spec was very limited in this regard.

        See my previous mail. I had written in this thread on June 7th
        regarding this proposal :

                "
		Take a look at the description below. The change is a
                simple function in the driver with a line or two added
                (considering BSD code) to the 'add multicast group'
                socket option.

                The suggestion works within the existing
                infrastructure with a minor addition.

                In existing implmementation the routing daemon on
                receiving an IGMP report adds the IP multicast group
                to the interface list. It tells the kernel to add the
                group by a socket option (in BSD/LInux
                implementations). The function after it adds the IP
                group to the interface can call the interface's device
                specific function - for IPoIB this function will ask
                the driver to join the IB group.

		(IGMP_report)--- n/w -> driver -> IGMP -> mrouted/gated
                                                        |
                                                    setsockopt(ADD_LGRP)
                                                        |
                                                        :
                                                        :
                                                        add_grp()
                                                        |
                                                ** call device_add_grp() **
                                                ** join relevant IB group **
                                                ** if needed            **

                Only the call marked with '**' is new. Nothing else.
                Note that the same function or similar function will
                have to exist on hosts for IP_ADD_MEMBERSHIP directive
                when a host application joins a particular IP group.
                In this case the router does the same thing on
                receiving an IGMP_HOST_MEMBERSHIP_REPORT.

                The change is simple and does not require changes to
                'every version of group mgmt code'. It does not
                require changes to routing daemons, nor does it imply
                large, complicated changes in OSes. "

For the rest, I am suggesting solutions based on the current state of the draft including the two enhancements regarding group create/delete traps you have mentioned. Promiscuous mode is not included in the IBTA specification.

Vivek