[ofa-general] Re: [openib-general] Fw: [PATCH] enable IPoIB only if broadcast join finish

[Shirley Ma]

Jason,

The bottom line of this patch is the same DAD bahavior w/o this patch,
let's see how DAD behaves w/i, w/o this patch:
1. If multicast join failure forever, then the IPv6 address is useless in
both cases, but IPv4 will work in fabrics w/i this patch, but IPv4 doesn't
work w/o this patch.
2. If multicast join successfully right away, then most likely we will
receive the NA on time, then there is no DAD issue in both cases.
3. If multicast join successfully within the DAD timer, most likely we will
receive the NA on time in both cases.
4. If mulitcast join succesffully after the DAD timer, then we have DAD
issue in both cases.

Only a tiny timing difference (a few lines code) w/i w/o the patch, that's
I don't understand why you think this patch impacts the DAD behavior, but I
think this patch does turn on carrier on on right time. Look at RFC IPoIB
in section 5:

Thus, the IPoIB link is formed by the IPoIB nodes joining the broadcast
group.  There is no physical demarcation of the IPoIB link other than that
determined by the broadcast group membership.

>If IPoIB is asked to send to a multicast address that is not yet
>joined (join is pending to the SA, or whatever) then it uses the
>broadcast MLID for the packet. This is similar to how ethernet works
>and would let DAD and RS work correctly in all cases.

Yes this is another patch I am working on. For IPv4 we use broadcast MLID,
for IPv6 we use all host multicast MLID for the packet. Here is the RFC
regarding not finding the multicast entry, but it only mentions remote
subnet, not for local subnet. We do need a patch for IB multicast join for
different subnets in the fabrics. It is missing in IPoIB right now.

10.  Sending and Receiving IP Multicast Packets
  Multicast in InfiniBand differs in a number of ways from multicast in
   ethernet.  This adds some complexity to an IPoIB implementation when
   supporting IP multicast over IB.

      A) An IB multicast group must be explicitly created through the SA
         before it can be used.
         This implies that in order to send a packet destined for an IP
         multicast address, the IPoIB implementation must check with the
         SA on the outbound link first for a "MCMemberRecord" that
         matches the MGID.  If one does exist, the Multicast Local
         Identifier (MLID) associated with the multicast group is used
         as the Destination Local Identifier (DLID) for the packet.
         Otherwise, it implies no member exists on the local link.  If
         the scope of the IP multicast group is beyond link-local, the
         packet must be sent to the on-link routers through the use of
         the all-router multicast group or the broadcast group.  This is
         to allow local routers to forward the packet to multicast
         listeners on remote networks.  The all-router multicast group
         is preferred over the broadcast group for better efficiency.
         If the all-router multicast group does not exist, the sender
         can assume that there are no routers on the local link; hence
         the packet can be safely dropped.

I had started another thread discussing the second patch before.

Thanks
Shirley Ma
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20070307/fa7f417a/attachment.html>