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

From: Bill Fenner <[email-masked]>
Date: Tue, 18 Jun 2002 16:38:35 -0700

Well, it would be a little difficult for the host driver to do exactly
what you describe:

>                        check for corresponding IB group
>                        if IB group exists 
>                                IB_join it
>                                IB_send report to group
>                        else
>                                IB_create IB group
>                                IB_send report to all-routers MGID or
>                                could send it to all-hosts group

The report is sent from the stack, not from the driver, so the driver
can't easily affect where it's sent.  The driver could send a seperate
message, though.

Let's take FreeBSD as a concrete example.

	Application calls IP_ADD_MEMBERSHIP
	  IP calls in_addmulti()
	    in_addmulti() calls if_addmulti()
	      if_addmulti():
		- increments the reference count if it exists
		- calls the media-family-specific multicast mapping routine
		  (if_resolvemulti() ) in order to get a media address
		  for this multicast address.
		  [presumably, in an IB network this contacts the
		   multicast server and finds out if there is an IB
		   group formed yet, and requests its creation if not.
		   Note that there's no kernel infrastructure in place for
		   this to take time, the mapping is expected to be
		   algorithmic.  Perhaps this routine could initiate
		   the exchange and return a placeholder, and packets
		   could be queued at if_output() until the protocol
		   exchange completes.]
		- calls the driver's IOCTL with SIOCADDMULTI to notify
                  that the list of multicast addresses changed.
            in_addmulti() calls igmp_joingroup() which may send one or more
              IGMP messages.

The only driver-specific portions are the last two pieces of if_addmulti() -
in particular, the sending of IGMP messages to a different group would
have to be performed by intercepting them in the normal if_output() routine,
e.g. examining every packet that is sent for a time after joining the
new group to see if it's the IGMP report and redirecting it.  That seems
a little hokey.

>        For example, in the case of BSD - a setsockopt()
>        DVMRP_ADD_LGRP is sent down by mrouted/gated in response to
>        IGMP_HOST_MEMBERSHIP_REPORT.

In my experience, this was last true in 1995 or 1996 when the kernel
was in charge of multicast routing.  The more recent architecture is
as I described earlier, i.e. the kernel just has a forwarding cache and
does not learn of group memberships on interfaces.

If the driver sends a special message when it creates a new IB group,
a system (like a multicast router) that is in multicast promiscuous mode
can join each of these groups.  Garbage-collecting might be difficult,
once you have only routers as members; a group might still be transiting
the IB subnet.

  Bill

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

---

From: Vivek Kashyap <[email-masked]>
Date: Thu, 20 Jun 2002 11:16:28 -0700 (PDT)

Bill,

        These proposals were made based on IB version 1.0 which
        provides no support of any kind for IB group create/delete
        notifications. So a way has to be found to let the router know
        of the IB groups being used or cause the routers to receive
        the packets in some way. One tack is to send notifications in
        a link level (driver based) protocol, the other was to use
        existing triggers (IGMP messages) and the third was to suggest
        the use of duplicate multicast packets (a copy to routers
        always in addition to the packet to the group).

        Given the lack of underlying support some ungainliness comes
        into the suggested solutions - so the aim has to be to reduce
        such ungainliness (in the protocol and individual
        implementations) but it can't be removed except by adding the
        necessary infrastructure to IBTA.

        With that in mind the IBTA is working on upgrading IB
        multicast support - if correctly done that should remove the
        need for any of the above solutions or leave only minor gaps
        to be filled in by IPoIB WG.

        The next version of IB specification is slated to come out in
        september. Jerry and I have removed the discussion of
        multicast forwarding and group managment from the
        link-and-multicast-02.txt draft (was section 10.0 in the
        -01.txt version). This issue can be taken up, if needed, after
        the next version of IB specification comes out.

        Driver based notifications (a separate low level protocol)
        would be another way to go if the IB spec doesn't deliver the
        necessary changes. Such a solution doesn't have the handicap
        of requiring IP stack changes since it can be localised to the
        drivers. But I believe the upgrades planned in IBTA will do
        the trick.

Vivek

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

---

From: Vivek Kashyap <[email-masked]>
Date: Thu, 20 Jun 2002 11:16:28 -0700 (PDT)

Bill,

Vivek