Re: Comments on draft-ietf-ipoib-link-multicast-04.txt
Vivek Kashyap <[email protected]>
| Newsgroups | gmane.ietf.ipoib |
|---|---|
| Message-ID | <[email protected]> |
My comments in <VK> below. Vivek -- Vivek Kashyap Linux Technology Center, IBM [email protected] [email protected] Ph: 503 578 3422 T/L: 775 3422 Roy Brabson/Raleigh/I To: [email protected] BM@IBMUS cc: [email protected] Sent by: Subject: Re: [Ipoverib] Comments on draft-ietf-ipoib-link-multicast-04.txt ipoverib-admin@ie tf.org 05/05/03 08:00 > > And shouldn't the IPoIB sender subscribe to the IB multicast group > > creation events using a wildcard MGID so that it can > > "SendOnlyNonMember" join the group if a listener appears on the local > > IB subnet, or "SendOnlyNonMember" join the all-routers group if a > > router appears on-link and creates the all-routers multicast group? > > And doesn't it need to subscribe to the IB multicast group deletion > > events so that it knows when to switch back to sending to the > > all-router multicast group and/or stop sending? > > An IP application may send the multicast packet to any group. One could > request that the interface be notified of every MGID creation/deletion but the > application(s) might never send any data to those groups. Therefore, > the wildcard report request is something that the implementation will > have to weigh against usage. The choice is upto the implementor. This wasn't clear to me from reading the spec. Let me see if I have this straight: - A listener MUST perform a "FullMember" join for the MGID of the multicast group <VK> It won't receive any packets otherwise as per IB specification. <VK> - A listener MUST be able to receive an IP multicast packet over either the broadcast GID or the MGID for the multicast group - A router MUST be able to receive an IP multicast packet over either the MGID, all-router MGID, or broadcast GID <VK> See the discussion on IP router below. <VK> - If there is an on-link listener, a sender may send the packet using either the MGID or to the broadcast GID <VK> I don't think the draft says that it is an either or between MGID and broadcast GID if the MGID exists. If the MGID exists the sender sends to the MGID. Oherwise it needs to send the packet to the router(s). Therefore the packet needs to be sent to the MGID corresponding to all-router address. <VK> - If there is not an on-link listener, a sender may send the packet to either the broadcast GID or the all-router MGID <VK> If there is no on-link listener then the sender should send the packet to the all-router MGID. I agree, as you had noted earlier, that if the all-router MGID doesn't exist then the packet can be dropped. <VK> Is that correct? And, if a sender wants to send packets using the MGID, it will need to listen for MGID creation/deletion reports so that it can switch between the MGID and the all-router MGID (or broadcast GID, I suppose) as on-link listeners join/leave the group. I do have to wonder whether having such a large number of optional mechanisms to handle the mapping of IP to IB multicasting is really a good idea. Would we be better off just selecting one approach and saying all IPoIB nodes should take that approach? <VK> Both IP and IB have similar concepts and use the same kind of words therefore let us append IP or IB in front of them. Instead of saying multicast group it is better to say IP multicast group or IB multicast group. If MGID is used then it is clear that IB is being talked about. IP listener: An IP listener would like to receive packets. For such a case the IP layer has to instruct the link layer to receive packets on the correspondingly mapped address. In the case of IB, the mapping is defined to the MGID. This is not enough. Therefore the link layer (IB) must IB_join the MGID as a FullMember. The MGID is created if it doesnt exist and the SM programs the fabric such that the packets are received by the listener. IP multicast router: An IP router must be able to receive the multicast packets and forward them if required - both into the subnet or out of the subnet. It gets to know of the groups by way of a routing protocol. Within the subnet IGMP/MLD are used. The router can therefore, on its link interface IB_join the MGIDs when it knows the IP multicast address(implementations don't seem to prefer this as per earlier discussions on this list) or it can listen promiscuously. In IB it cannot listen promiscuosly; therefore the router needs to request MGID creation/deletion reports from the SA/SM and the routers IB_join/leave groups on receiving the reports. The router gets to know of the IP groups to forward to from running a routing protocol. If there are no IP listeners (and hence no corresponding IB MGIDs)in the subnet and the router doesn't create the corresponding MGID itself(as noted in the previous paragraph) then there is no way that IP packets destined for the remote IP multicast address can reach the router unless the packet are sent to an MGID the router is already a member of such as the all-router address. Therefore, in the absence of the relevant MGID the sender needs to send the packet to the all-router MGID. This implies that the router needs to be able to receive IP multicast packets on the corresponding multicast MGID or the all-router MGID. Since a router really wants to receive packets as well as send packets it needs to IB_join as a FullMember or as a NonMember. A Non-Member IB join is preferable in that it doesn't effect the creation/tearing down of the MLID forwarding built into the switching fabric. But an implementation can choose to IB join as FullMember if it so prefers. This is not an option from IPoIb but just what IB provides. IP sender: Any IP host can send to any IP multicast address without itself being a member of the IP group. This is not always the case at the IB layer since the the switches need to be programmed to forward the MLID. Therefore a sender needs to map the IP multicast address to the corresponding MGID (as per mapping defined in this draft) and then IB join the MGID. It can then transmit the packet to the MGID. If there are IP listeners then there will be a corresponding IB MGID that the sender will IB_Join. The router, because it IB_joins all new IB MGID creations (see above) will also be a member and receive the packet. If there are no local subnet IP listeners, the corresponding MGID wouldn't exist. In such a case sending to MGID corresponding to all-routers IP multicast address ensures that the multicast addresses are receieved by the router. One could also argue that the sender should, instead of the SendOnlyNonMember join do a FullMember join. Then the MGID will be created if it doesn't exist and the router will join in on receiving the creation report. But, there is very likely a delay between the creation of the MGID, the report to the router and the router joining the MGID; during this delay the packet is likely dropped. Multicast is not reliable but in this situation the chances of loss are quite high and hence it is not a preferable way of transmitting multicast packets. Vivek > > It does seem like a reasonable thing to request creation/deletion > report on the all-router multicast GID. > > > > > > But I'm wondering why a node needs to do this at all. Wouldn't it > > make more sense for the IPoIB node instead create the multicast group > > and join the group so that IPoIB multicast routers can join the group? > > Yes, the IPoIB sender will need create the group as a "FullMember", > > but this seems to provide a simpler mapping of IP multicast to IB > > multicast. > > It will work but how is this a better thing to do ? I also > do not think that such behavior can/should be disallowed. I'm just trying to understand if there is some way to simplify the mapping of IP multicast groups to IB multicast groups. My main concern is with listening for IB group creation/deletion reports so a sender can tell if/when to use the multicast group's MGID and when to use the all-router MGID. If the sender performs a "FullMember" join, then it will always send using the MGID for the corresponding IB multicast group. But, based on what you said above, a sender can always use the broadcast GID when sending to a multicast group for which it is not also listening. This does simplify the logic, but at the cost of forcing every IPoIB node to filter the IP multicast packets for which they are not interested. Then again, it saves the SM from having to reprogram the switches/routers in the IB fabric when the sender performs a non-member join. To be honest, I have no idea how to go about making a rational choice on which approach will yield the better results. Roy _______________________________________________ IPoverIB mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ipoverib