On Tue, 2005-09-13 at 12:29, Michael S. Tsirkin wrote: > Quoting r. Roland Dreier <[EMAIL PROTECTED]>: > > 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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
