[openib-general] Multicast address aliasing in IPoIB

[David M. Brean]

Hello,

[I saw your recent email regarding the a potential request to change the 
I-D at the next IETF meeting, so decided to reply using this email, 
since it describes the problem.]

The IBTA allows multiple MGIDs to map to a MLID.  That is the aliasing 
mechanism on IB.  As a result, it seems ok to have IP multicast 
addresses to map 1-1 to MGIDs.  As you know, the IPoIB multicast 
hardware address is a special format of the MGID.

So, the OS should not need to map more than one IP multicast address to 
a IPoIB hardware address.  [There are other steps needed to program the 
CA interface and obviously the SM must perform some internal mapping 
management.]

Does that solve the problem?

-David

Dror Goldenberg wrote:

> IPoIB defines no aliasing in the mapping of IP multicast address into 
> IPoIB HW addresses.
> In Ethernet, there is an aliasing, i.e. more than one IP address can 
> map into the same
> Ethernet multicast MAC address.
>  
> In short: IP to Ether takes 24 LSbits from the IP address
>              IP to IB takes 28 LSbits from the IP address (which are 
> essentially the whole
>                 IP address, the remaining 4 bits are "class D prefix").
>  
> The problem is that the current IPoIB driver interfaces the Linux 
> kernel as if it were
> an Ethernet driver. Therefore, the IP layer will not notify the 
> net_device when a new MC
> address is added if it maps to the same MAC address. It will rather 
> increment the
> reference count of the MAC address (net_device->mc_list->dmi_user) and 
> won't call
> net_device->set_multicast_list().
> Therefore, if a user just adds itself to an IP MC group (setsockopt with
> IP_ADD_MEMBERSHIP), then if the IPoIB driver already has this Ether 
> MAC address
> in its filter because of a previous registration to another IP MC 
> group, then the IPoIB driver
> will not get any notification, and the user will not get registered to 
> the MCG.
>  
> I was wondering what should be the solution for that in the current 
> kernels (gen1) and
> in future kernels (gen2).
>  
> For gen2, will it be possible to define a new medium for the IPoIB 
> driver (not ARPHRD_ETHER),
> such that arp_mc_map() will map the entire IP address into the HW 
> address ? Today it looks
> impossible, because arp_mc_map() just overrides bits 31:24 of the IP 
> address.
> For gen1, what is that we can do ? Is there a way to obtain such an 
> event from the in_device ?
> If not, then I don't see any clean escape. Is it possible to 
> periodically check out the in_device
> multicast list and see if anything has changed ? would that cause any 
> problem during the transition
> periods ? Any other idea of how to do that without a kernel patch ?
>  
> - Dror
>  
> * For reference:
>     The algorithm for mapping IP mcast address to Ether mcast address 
> is defined in 
>     RFC 1113 section 6.4., and for IB in 
> draft-ietf-ipoib-ip-over-infiniband-07.txt section 4.0.
>  
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>openib-general mailing list
>openib-general at openib.org
>http://openib.org/mailman/listinfo/openib-general
>
>To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>  
>