Subject: [ipoverib] IP Multicast and IGMP's

From: Yaron Haviv <[email-masked]>
Date: Tue, 09 Apr 2002 19:12:24 +0200

This email refers to previous emails by Vivek raising the problems presented
by IP Multicast and proposes 2 possible solutions

In the Ethernet model, there is no explicit Join in Layer 2
Most Ethernet switches treat Multicast as Broadcast, the few that don't do
"IGMP Snooping" and peek into the layer 3 data
Learning the multicast tree and filtering traffic (however this method is
note widely used)
This way joining or leaving an MC Group doesn't involve any changes to the
fabric
The receiving nodes does the filtering to make sure only the appropriate MC
data is received

IB model is different since you must explicitly join the group, not to
mention all the info you need such as MTU, MLID, etc'
So you cannot just send an IP packet like in Ethernet and it works, you must
first join the club, and also get the MCGroup info

We have 2 options, one is to treat the multicast GID's like broadcasts (use
a broadcast LID, or the same IPoIB partition MLID)
Any time we see a Multicast IP address or HW (GID) address, we attach the
IPoIB broadcast MLID & MTU to it and send it away
This will also make sure that all IPoIB nodes will receive the packet, we
just need to make sure that the HW doesn't through away the packets by
either have a multicast promiscuous mode (not filter MGID's, just MLID's),
or by adding a new MGID to the HW on each join to a new IP Multicast group

The other method is to implement an "IGMP Snooping" like mechanism at the
IPoIB driver, when an IGMP message is sent, first contact the SM and join
the group, as well as get the required path info (MTU, MLID, ..), and
program the HCA
When the multicast message will be sent the path would already be set, if
for some reason the sender is not yet a part of the MC Group, it could first
contact the SM and join
It should also be noted that the snooping should be done on arriving IGMP
messages, since the IP stack might choose not to send an IGMP message since
it sees that the subnet already joined the group and the router is already
aware of it.
(IGMP's are mainly used for the routers o know if there is ANY node in this
subnet belonging to the IP Multicast group)

I personally prefer the first approach, since it is much simpler to
implement, and it also follows the common Ethernet model

Yaron

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

---

From: Vivek Kashyap <[email-masked]>
Date: Wed, 10 Apr 2002 11:31:29 -0700 (PDT)

> or by adding a new MGID to the HW on each join to a new IP Multicast group

        This is equivalent to proposal (i) that I presented. Use a
        single hardware broadcast group. 

        Such a solution just ignores all the benefits of having
        multiple multicast groups. All the packets are broadcast and
        all are received by everybody. They then filter them in
        software. 

        I would suggest that we go for a solution that allows us to
        benefit from the multicast support available from the
        hardware. 

> The other method is to implement an "IGMP Snooping" like mechanism at the

        The reason I didn't pursue 'IGMP snooping' is because it
        requires all IPoIB drivers - whether in routers or end hosts -
        to parse every multicast packet or at least every multicast
        packet received on all-routers MGID - for IGMP/MLD packets and
        then take action.

        Therefore I came up with the solution that I presented which
        requires much more limited changes and does not require
        looking at every IP multicast packet to see if it is a valid
        IGMP/MLD report. 
> the group, as well as get the required path info (MTU, MLID, ..), and

        This is the same as saying that when IP_ADD_MEMBERSHIP is done
        i.e. an IP node decides to join an IP group then IB_Join the
        corresponding IB group. [ Note that MTU is not going to be
        different - we have mandated that all MTUs in all the groups
        have to be the same as that for the broadcast_GID.]

	Then send an IGMP report.  

        -- we are in sync till the above. This is where I have
        suggested the additional function given below:

        What I have suggested is that the IP router will not receive
        the report unless it is sent out on the broadcast_GID or on
        the all-routers-GID. It is better to send it out on the
        broadcast_GID so that all other hosts receive it too.

        A little enhancement:

        In my proposal the node sends the IGMP report on the MGID
        corresponding to the broadcast/all-routers multicast IP
        address only when the node IB_creates the IB group. Since, at
        that time the router does not know of the new group.

        If it is just IP_joininig the group it only needs to IB_Join
        the group at the IB layer but the IGMP report is then sent to
        the corresponding IB MGID and not the broadcast MGID.

> subnet belonging to the IP Multicast group)

        In my proposal the rest of the solution lies with the router.
        The router gets the IGMP packet and parses it in the normal
        way. It even sets the IP groups to forward to in the normal
        way. 

        ***The router is being asked to merely IB_Join the IB group when
        it hears of a new IP multicast group.**

        Note that I have bounced this off of Bill Fenner(routing area
        AD) and he thinks it is ok to ask the router to do the above.

	We could combine the soluion in another way:

        Keep all the requirements on the sender and the host that I
        have said already.

Vivek

-- 
Vivek Kashyap
Linux Technology Center, IBM
[email-masked] 
[email-masked] 
503 578 3422 (o)