Subject: RE: [Ipoverib] Bit number of IP address in MGID

From: "Larsen, Roy K" <[email-masked]>
Date: Wed, 6 Feb 2002 09:36:48 -0800

Koji,

I'll let the authors of the link multicast draft address your question on
the appropriate number of bits used in mapping to IBA multicast addresses.
However, I can give you my opinion about compatibility with other links.

The IPoIB work is not an Ethernet emulation protocol.  It is the
encapsulation of IP protocols over an IBA link.  Obviously a protocol design
needs to be implementable within an OS.  However, I would resist a design
that was tailored to one that only supports Ethernet.  I know DLPI is a
protocol independent interface.  Reference

http://www.opengroup.org/onlinepubs/009618899/apdxd.htm#tagcjh_09

What is your DLP returning in the DL_INFO_ACK as the dl_mac_type?  Now that
we have an official ARP hardware type (thanks Vivek), perhaps those working
with SVR4 can have that type added to the current list of dl_mac_type
defines.  I assume it would have to use DL_OTHER in the mean time.

Roy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, February 05, 2002 10:44 PM
To: [email-masked]
Subject: RE: [Ipoverib] Bit number of IP address in MGID

Vivek, Roy,

What is the merit of 80bits for IPv6 and 28bits for IPv4 ? 
I think 32bits for IPv6 and 23bits for IPv4 are enough. 

If we use 32bits for IPv6 and 23bits for IPv4,
the lower bits of the multicast address which are used by ipoib driver
become compatible with Ethernet.
I think if an interface can be compatible with the current one,
it is better to be so.

Koji

> Koji,
> 
>         DL_ENABMULTI_REQ primitive includes the multicast address
>         length. Your implementation needs to be modified as needed for
>         the IPoIB link.
> 
>         As far as I know the complete multicast address (and therefore
>         dependent on the link) needs to be passed to the driver. So
>         reducing the number of the bits in the mapping really has no
>         effect anyway.
> 
> Vivek

> Koji,
> 
> For Linux, this is not problem.  The upper layer software is link device
> independent.  When a link specific operation needs to be performed, like
> mapping a multicast address to a link multicast filter, it performs a
> switch-case on the link device type.
> 
> So, for IPv4, there is a arp_mc_map() function which contains a
switch-case
> that is currently sensitive to Ethernet, FDDI, IEEE802, and Token Ring.
To
> fit into this infrastructure, I'll need to add a case for IPoIB.  I grant
> you that this does require a source code change, but the source is freely
> available and the infrastructure is setup to add new link types.  We'll be
> working with the Linux community to accept IBA as a supported link in
future
> Linux releases.
> 
> I thought DLPI was also link independent.  Why is passing in an Ethernet
> address?  Can SVR4/Solaris only support Ethernet link types?
> 
> Roy

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

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

---

From: Vivek Kashyap <[email-masked]>
Date: Thu, 7 Feb 2002 16:24:36 -0800 (PST)

I agree with Roy that IPoIB is not an Ethernet emulation protocol but
is encapsulation of IP over IBA link. Keeping with that thought it is
best to leverage the benefits the link provides. Therefore we use as
many bits as are available to map the various IP multicast groups to
different IB multicast GIDs. For example, there are 28 significant
group bits in IPv4 host group addresses; by using 28 bits we map them
all independently to different MGIDs. Ethernet was constrained to map
multple groups to the sameethernet multicast address.

Vivek

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

---

From: [email-masked]
Date: Fri, 08 Feb 2002 11:08:48 +0900

Vivek, Roy,

I don't agree with 28 bits for IPv4 and 80 bits for IPv6.
How much merits do 28 and 80bits could give us ?

1. It's true that IPoIB does not aim to Ethernet emulation,
  but IPoIB should aim to get more spread in market as much as we can do.
  I believe using more "exising IP stacks, etc", give more merits
  for us to let IPoIB spread in market.
2. I doubt how more merits extending 23 to 28bits in IPv4 and 32 to 80 bits
  in IPv6 can give us to differentiate nodes in multiple multicasts.
  32 bits for IPv4 and 128 bits for IPv6 are perfect. But we don't do so.
  And 28 and 80 bits are incomplete (Not perfect, Not less suit for exsitings).
  I think 23 and 32 bits are best suitable for IPoIB.
3. Also in Linux and BSD case, to suit to 28 bits and 80 bits, adding or
  rewriting the macro is needed.

>multple groups to the sameethernet multicast address.

Thanks,
Akihiko

>> > address?  Can SVR4/Solaris only support Ethernet link types?

---------------------------------------------------------------------------
  今井昭彦  川崎市中原区上小田中4-1-1 川崎工場 本館 16階 北側
  TEL(内) 7113-8706,    TEL(外) 044-754-3456, 044-777-1113*38706

---

From: Vivek Kashyap <[email-masked]>
Date: Fri, 8 Feb 2002 00:35:11 -0800 (PST)

>   for us to let IPoIB spread in market.

Yes, but that works with adding in IPoIB specific modules. You are
suggesting using the DL_ETHER type for IPoIB - that looks a lot like
emulation. 

>   I think 23 and 32 bits are best suitable for IPoIB.

        28 bits is the maximum for IPv4. The multicast addresses begin
        with : 0xE0 (224.x.x.x.). So using 28 bits ensures that each IPv4
        multicast addresses maps to a separate link multicast
        address. More bits are not needed.

        We did specify 32 bits for the broadcast GID though. In
        ethernet links the broadcast address maps to a 48 bit
        address(all 1s).

        In the IPv6 case there are 112 bits available. The draft has
        provided for 80 bits. So 2^32 groups are mapped to a single
        MGID. With using only 32 bits we would map 2^80 multicast
        addresses to a single MGID.
Vivek

---

From: "Bill Strahm" <[email-masked]>
Date: Sat, 9 Feb 2002 12:14:08 -0800

Just to be clear on IPv4 multicast addresses, it covers a range from
224.0.0.0 - 232.255.255.255... leaving us with 27 bits to stuff for a
multicast address.  Ethernet uses 24 of these bits leaving you with 8 IP
multicast addresses for each ethernet broadcast address...
(I hope I got the math right)

Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Vivek Kashyap
Sent: Friday, February 08, 2002 12:35 AM
To: [email-masked]
Cc: Vivek Kashyap; [email-masked]
Subject: Re: [Ipoverib] Bit number of IP address in MGID