Before any UD QPs can become members of a multicast group, the group must be created. A UD multicast group is created in the following manner:
1. | An administrative application (outside the scope of the specification) creates a UD multicast group by creating an MCGroupRecord in the SA database (“MCGroupRecord” on page 969 defines how this is accomplished). When creating the database record, the application may either specify the multicast GID address that will act as the group identifier or it may leave it to the SA to assign an available multicast GID address. |
2. | When the application instructs the SA to create the group record in its database, the SA automatically assigns a multicast LID address identifier for the group and returns it to the administrative application. It also returns the assigned multicast GID address that identifies the group. |
3. | When the new group record is created:
|
A UD QP in the local HCA is made a member of a UD multicast group on the HCA by calling the Attach QP to Multicast Group verb. If the HCA doesn't support multicast UD groups, this verb does not have to be implemented. When called, the following input parameters are supplied to the verb:
HCA Handle.
Multicast group DLID (this was returned by the SA when it created the group).
Multicast group IPv6 Address. This is the 128-bit GID address that either the administrative application or the SA assigned to the group.
QP Handle of the UD QP to be made a member of the group.
To add the QP and its respective port to the group, the verb:
Interacts with the SA to cause a MCMemberRecord to be added to the SA database.
Interacts with the HCA device driver to add this QP and the port it's associated with to the group data structure within the HCA (see “Creating a Group” on page 566 and refer to Figure 22-2 on page 565).
After the call completes successfully, this QP will be provided with a copy of every inbound or outbound UD multicast message addressed to the specified group (identified by the DGID address) received on or sent through any HCA port.
One or more HCA UD QPs may be attached to (i.e., become members of) a multicast group on the HCA. In order to receive packets sent to the multicast group, every QP attached to a particular multicast group must be a member of the same partition as the partition of the incoming packet.
If the maximum number of multicast UD QPs have already been attached to the group, an attempt to attach another UD QP to that group results in the verb's return of an immediate error indicating that there are insufficient resources.
A single QP can be a member of multiple groups but can only send and receive messages via one HCA port. If a software application local to the HCA wishes to receive multicast traffic inbound on multiple HCA ports, it must associate a separate QP with each of those ports.
The following is a detailed description of the procedure used to attach a UD QP and its respective CA port to a group:
1. | The application program desiring to receive messages sent to a specific multicast group defines or determines (in a manner not defined in the specification) which group it wishes to become a member of (i.e., the multicast GID address it will be associated with). |
2. | An administrative application determines whether the CA associated with the application program is already participating in the multicast group:
|
3. | The administrative application adds a MCMemberRecord to the SA database as described in “MCMemberRecord” on page 972. The SA performs the following steps upon receiving the new record:
|
4. | The SA then adds the QP and its respective CA port as a member of the group. |
When a multicast UD message is to be sent to all members of a group, the DLID and DGID addresses are specified as part of the Address Handle that is included in the WR posted to the QP's SQ. All multicast UD packets have a GRH as well as an LRH. When the source port transmits the packet to that group, it uses the multicast LID and GID as the DLID and DGID addresses, respectively.
Multicast UD packets are handled as follows by switches and routers:
The multicast DLID address causes all switches that receive the packet to broadcast the packet through one or more ports (as a result of a lookup in the switch's Multicast Forwarding Table—see “Multicast Forwarding Table Implemented” on page 675, or by being forwarded through a default port—see “Multicast Packet Handling When Table Is Not Implemented” on page 675).
The multicast DGID address causes all routers that receive the packet to perform a lookup in their routing tables and, if the lookup indicates that the router must forward the packet to one or more attached subnets, it broadcasts the packet through one or more ports.
Refer to Figure 22-3 on page 571. If any UD QPs within the same CA as the UD QP sending the multicast message are members of the group identified in the packet's DGID field, the CA must, in addition to transmitting the packet out onto an IBA link, distribute the packet internally to the RQ Logic of each of the internal member UD QPs. This is referred to as multicast loopback.
When a CA port receives a multicast UD packet, the port's Link Layer verifies that both of the following are true:
That the group identified by the packet's multicast DGID address is registered within the CA (i.e., it exists in the Group Lookup Table).
That the packet's BTH:DestQP field contains QPN FFFFFFh.
If the packet fails either or both of these checks, it is discarded. If it passes both of them, the Link Layer distributes the packet to the RQ Logic of all UD QPs that are members of that group (see Figure 22-1 on page 564).
When an application program wishes to leave a multicast UD group, the following procedure is used:
1. | |
2. | If no more UD QPs attached to the same CA port are members of this multicast group, the leave implementation informs the SM/SA that this CA port should no longer receive multicast UD packets targeting this group. The SM/SA updates the switch and router route forwarding tables to effectively remove this CA port as a target for packets associated with this multicast group. |
The input parameters for the Detach QP From Multicast Group verb are:
HCA Handle.
Multicast group DLID.
Multicast group IPv6 Address.
QP Handle.
This verb is required only if IBA UD multicast is supported by the HCA.
When an administrative application determines there is no need for a multicast group or that no local CA ports have associated UD QPs that are members of the group, the multicast group may be deleted. Upon receiving the delete request, the SA takes the actions described in “MCGroupRecord” on page 969 to delete the MCGroupRecord from the database. In addition, the SM informs each router within this subnet that this CA is no longer participating in the associated multicast group.
To improve fabric efficiency, the SA should periodically verify that all CA ports and routers that are members of a multicast UD group are still participating and, if they are not, it should prune them from the multicast UD group as described in “Leaving a Group” on page 571. How often the SA performs this verification is outside the scope of the specification.