[openib-general] Re: ipoib send-only join to IGMP multicast group

[Hal Rosenstock]

On Tue, 2005-09-13 at 12:29, Michael S. Tsirkin wrote:
> Quoting r. Roland Dreier <rolandd at cisco.com>:
> >     Jack> 2. Who is responsible for creating this multicast group in
> >     Jack> IPoIB? (A send-only join will not cause a group to be
> >     Jack> created if it does not yet exist)
> > 
> > The group will be created if any full-member joins are done.
> 
> Forgive me if I'm asking a dump question - but wouldnt it be simpler
> to join as a full member?

It would just need the additional characteristics for that group which
are available from the broadcast group.

> It seems that if we are joining a group and it doesnt exist,
> we have to handle this specially by forwarding packets to
> all-IP broadcast group.
> Further, since the group can be added/deleted at any time.
> it seems that we also should request, and handle,
> delete updates and 'creation' reports from the SM.
>  
> > But that
> > won't happen unless some entity wants to receive packets from the
> > group -- in other words, some multicast router.
> 
> The ipoib draft seems to imply that routers should typically
> perform nonmember joins. Do I misunderstand it?

No and these nonmember joins are based on it subscribing to MGID
created/deleted notices..

This is all covered better in the IPoIB Architecture I-D
http://www.ietf.org/internet-drafts/draft-ietf-ipoib-architecture-04.txt

IPmc senders join groups either as send only (nonmembers) or full
members.

        A pure sender may choose to join the multicast group as a
        FullMember. In such a case the sender will receive all the
        multicast packets transmitted to the IB group. Additionally,
        the IB group will not be deleted until the sender leaves the
        group.

        Alternatively, a sender might IB_join as a SendOnlyNonMember.
        In such a case the packets are not routed to the sender though
        packets transmitted by it can reach the other group members.
        Additionally, the group can be deleted when all FullMembers
        have left the group. The sender can further request delete
        updates from the SM.

All that is said about receivers is that they need to join and create
the group if necessary.

        The IP host must join the IB multicast group corresponding to
        the IP address. This follows from the IBA requirement that the
        receiver must join the relevant IB multicast group.  The group
        is automatically created if it does not exist [IB_ARCH].

        The IP receivers must IB_leave the IB group when the IP layer
        stops listening of the corresponding IP address. The SM can
        then choose to delete the group.

IP multicast routers need to listen promiscuously and joins these
discovered groups as nonmembers.

        IP routers know of the new IP groups created in the subnet by
        the use of protocols such as IGMP/MLD. However, this is not
        enough for IPoIB since the router needs to IB_join the
        relevant IB groups to be able to receive and transmit the
        packets. There is no promiscuous mode for listening to all
        packets.

        The IPoIB routers therefore need to request the SM to report
        all creations of IB groups in the fabric. The IPoIB router can
        then IB_join the reported group. It is not desirable that the
        router's IB_joining of a multicast group be considered the
        same as the IB_join from a receiver - the router's IB_join
        shouldn't disallow the group's deletion when all receivers
        leave. To overcome just this type of situations, IBA provides
        the NonMember IB_join mode.

        The NonMember IB_join mode can be used by IP routers when they
        join in response to the create reports. A router should
        ideally request the delete reports too so that it can release
        all the resources associated with the group. T

-- Hal