UD Multicasting

Creating a Group

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:

- The administrative application causes the creation of the group within the HCA. Exactly how this is accomplished is HCA implementation-specific. Basically, the administrative application would instruct the HCA device driver to create a group data structure within (or accessible by) the HCA (refer to the item labelled “Group Table” in Figure 22-2 on page 565). Whenever an incoming multicast UD packet arrives at any of the CA ports, the HCA logic consults this data structure to determine which, if any, UD QPs are members of the group specified by the packet's GRH:DGID field.

- In addition, software may notify the appropriate routers on the subnet of the new group (the manner in which this is accomplished is outside the scope of the specification). The router update protocol used to accomplish this should determine whether this multicast group is already in operation within another subnet. If so, the router returns the PMTU of the existing multicast group to determine whether the create is allowed or not.

Attaching an UD QP and Its Respective Port to a Group

Accomplished by a Verb Call

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.

Detailed Description

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:

- If it is, the application program creates a new local UD QP and performs the steps required to join this group (steps 3 and 4 that follow).

- If not, the application program creates a UD multicast group by creating a 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.

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:

- Validates that the multicast group address already exists and fails the join operation if it is invalid.

- Validates the requested PMTU and fails the join operation if the prospective member QP's PMTU is greater than that of the group.

- Verifies that a switch (if any) attached to the QP's port is capable of multicast operation. The switch either supports multicast operation via the optional Multicast Forwarding Table (see “Multicast Forwarding Table Implemented” on page 675) or, if the table isn't implemented, via the SwitchInfo.DefaultMulticastPrimaryPort and SwitchInfo.DefaultMulticastNotPrimaryPort switch attribute elements (see “Multicast Packet Handling When Table Is Not Implemented” on page 675).

- If the multicast group already exists and is already in operation within this subnet, the following actions are taken:

- Verify that all switches and routers participating in this multicast group can support the requested PMTU. If they cannot, the join operation fails.

- Each multicast group is implemented by defining a logical routing tree across the participating switches. Rebuild or modify the routing tree to include the new CA port. The SM/SA tells fabric management to update the associated route forwarding tables within all switches and routers to reflect this new topology.

- If the multicast group does not exist within this subnet, take the steps defined in “Creating a Group” on page 566.

- Each router within this subnet is informed of the successful multicast join operation. Routers invoke the appropriate multicast group management operations to add this subnet as a participant in the associated multicast group. This protocol is outside the scope of the IBA specification.

4.
The SA then adds the QP and its respective CA port as a member of the group.

All UD Multicast Packets Have a GRH

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.

Distribution of a Multicast UD Packet within Network

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.

Distribution of a Multicast UD Packet within CAs

Packet Distribution Within the Source CA

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.

Figure 22-3. Multicast UD Loopback


Packet Distribution within a Destination CA

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).

Leaving a Group

When an application program wishes to leave a multicast UD group, the following procedure is used:

1.
Using the Detach QP From Multicast Group verb call, the application's QP is removed as a member of the multicast group. The verb removes the corresponding MCMemberRecord from the SA database. If additional local UD QPs are still members of this multicast group, no further action is required.

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.

Deleting a Group

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.

Pruning

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset