SM States

Discovering State

Refer to Figure 30-2 on page 860. There are three circumstances under which an SM enters the Discovering state:

• Upon startup.

• If it doesn't get a response from the Master SM when it performs a SubnGet(SMInfo) to read the Master's SMInfo.ActCount element.

• Upon receipt of a SMP Control Packet commanding it to enter the Discovering state.

Once it has entered the Discovering state, the SM uses SMPs to discover all of the nodes in the subnet. During this process, the SM may or may not encounter another device that contains an SM. There are two possible cases:

Case 1. No other SMs. If it has completed subnet discovery and hasn't discovered any other SMs, the SM takes the following actions:

- Changes its state to the Master state.

- Sets the SMInfo.SMState attribute element of the port it resides behind to indicate that it is in the Master state.

- Using SubnSet(PortInfo) SMPs to write to each port's PortInfo. MasterSMLID and PortInfo.MasterSMSL, it tells all ports in the subnet:

- the LID address of the port the Master SM resides behind.

- the SL that should be used when sending any packets—i.e., SubnTrap(Notice) SMPs—to the Master SM.

Case 2. Additional SM(s). The SM may discover one or more additional SMs in the subnet. It does this by reading the following attribute elements:

- PortInfo.CapabilityMask.IsSM. This bit is set to one if an SM resides behind a port. However, if the element described in the next bullet item is set to one, the SM residing behind a port is disabled.

- PortInfo.CapabilityMask.IsSMDisabled. This bit indicates whether or not the SM behind this port is enabled or disabled.

If the SM discovers another SM, it takes one of the following actions:

- If the newly discovered SM has a higher-priority than this SM, this SM changes its state from Discovering to Standby.

- If the newly discovered SM has a lower-priority, this SM stays in the Discovering state and continues its subnet sweep.

Note that if the SM discovers a device but doesn't have the appropriate M_Key (Management Key) to access its attributes, the SM should “notify a higher-authority” (e.g., software). The M_Key is described in “Management Key (M_Key)” on page 324.

Master State

Figure 30-3 on page 864 and Figure 30-4 on page 865 illustrate the SM's actions while in the Master state.

Master SM's “Heartbeat”

The Master SM increments its SMInfo.ActCount attribute element whenever it issues an SMP or performs any other management function. This is its “heartbeat.”

Master Responds to SMPs Issued by Other SMs

The Master SM must respond to SubnGet(SMInfo) or SubnSet(SMInfo) attribute reads or writes issued by other SMs for the following reasons:

• SubnGet(SMInfo) SMPs are issued by:

  - Standby SMs checking to see if the Master's SMInfo.ActCount attribute has incremented.

  - Other Master SMs checking to see what state this SM is currently in (by reading its SMInfo.SMState).

• SubnSet(SMInfo.SMState) SMPs are issued by another Master SM commanding this Master SM to change its state (to Standby or to Not-Active).

Whenever the Master SM receives an SMP containing an SubnGet(SMInfo) or a SubnSet(SMInfo), it responds by issuing an SubnGetResp(SMInfo) SMP returning the state of SMInfo (on a read or a write).

The reader should note that the Master SM will only respond to an SMInfo read or write if the M_Key (Management Key) supplied in the requester's SMP matches the Master SM's M_Key. A detailed description of the M_Key can be found in “Management Key (M_Key)” on page 324).

Master Periodically Sweeps Subnet

At an interval defined by the OS, the Master SM sweeps the subnet to determine if any devices have been added or deleted, or have failed. By “sweep,” the specification is referring to the discovery process described in the chapter entitled “Discovery” on page 871.

Master SM Maintains a Path Database (in SA)

The Subnet Administrator (SA) is usually implemented as a subset of the Master SM. The SA is a database wherein the Master SM records the topology of the subnet, how each attribute of each device is currently programmed, and all possible paths that exist between the ports of each and every CA and router within the subnet.

On Device Removal, Update Database

When the Master SM detects that a device has been removed from the subnet [either while performing a sweep or because it received a SubnTrap(Notice) from a device's SMA], it updates its path database to reflect the altered topology.

When New Device Detected, Master SM Probes Added Path(s)

When the Master SM detects the presence of a new device, it configures the device and also updates its path database. Note that the hot installation of a switch would add multiple paths to the subnet, and the Master SM must then probe all of the added paths. A newly discovered device may or may not contain an SM.

newly Added Device(s) May Contain SM(s)

If a newly added device contains an SM (as indicated by a one in its PortInfo.CapabilityMask.IsSM bit), the Master SM must make a determination as to whether or not to yield subnet management to the newly discovered SM. There are two possible cases:

Case 1. Newly discovered SM is a master (its SMInfo.SMState element = Master state). There are two possible cases:

- New SM has higher priority. In this case, the Master SM reads the other master's SMInfo.SM_Key element to see if it has the proper key to manage this subnet. There are two cases:

• New SM has the proper key. In this case, the Master SM completes the discovery process and then yields to the Master with the higher priority and the proper SM_Key. The Master SM sends a Handover Control Packet to the higher priority SM and continues to respond to SubnGet(SMInfo) requests issued by Standby SMs to read its ActCount. The higher priority master is required to return an Acknowledge Control Packet when it receives the Handover Control Packet. When the lower priority Master SM receives the Acknowledge, it enters the Standby state.

• New SM does not have the proper key. In this case, the Master SM reports this as an error to a “higher authority” (i.e., to software).

• New SM has lower priority. In this case, the Master SM awaits the receipt of an Acknowledge Control Packet from the other SM. Receipt of the Acknowledge verifies that the other SM has relinquished management of its portion of the subnet and has entered the Standby state. The Master SM then continues its sweep and configuration of new devices.

Case 2. Newly discovered SM is not a master (it's in the Standby state). In this case, the Master SM checks the new SM's priority:

- If the newly discovered SM has a lower priority than the Master SM, the master does not yield to it and just continues its sweep of the subnet.

- On the other hand, if the newly discovered SM has a higher priority, the Master SM may either yield to it or not:

• If it chooses not to yield to it, the Master SM just continues its sweep of the subnet.

• If it chooses to yield, the Master SM sends a Handover Control Packet to the higher priority SM and continues to respond to SubnGet(SMInfo) requests issued by Standby SMs to read its ActCount. It may or may not receive an Acknowledge Control Packet back from the higher priority SM (the specification is fuzzy here). If it does receive an Acknowledge, the Master SM responds with a SubnGetResp(SMInfo) packet and then enters the Standby state. If it doesn't receive an Acknowledge, it just quietly enters the Standby state.

Standby State

Refer to Figure 30-5 on page 867 and Figure 30-6 on page 868 (a continuation of the flow in the previous figure).

As mentioned earlier, a SM in the Standby state periodically polls the Master SM by performing a SubnGet(SMInfo) to read the Master's ActCount. The polling interval is defined by the OS and is outside the scope of the specification.

In the event that the Master SM does not respond to the ActCount read, the Standby SM re-enters the Discovering state (see “Discovering State” on page 858). It also does so if the Master's ActCount has not been updated since the previous time it was read.

In addition to the performing the periodic ActCount reads, the Standby SM must respond to any Control Packet (see “SM Control Packets” on page 855) that it may receive. A Control Packet may command the Standby SM to enter another state (Discovering or Not-Active), or it may be a Handover packet.

If the Standby SM receives a Handover packet, it takes the following actions:

• Returns a SubnGetResp(SMInfo) packet.

• Reads the current topology information from the SA (to update its own SA database) using a SubnAdmGetBulk() (for additional information, refer to “Fetch Entire Database” on page 948).

• Tells all ports in the subnet the LID of the port behind which it resides (by writing its LID address into each port's PortInfo.MasterSMLID attribute element), as well as the SL they should use when sending packets to the Master SM (by writing an SL value into each port's PortInfo.MasterSMSL attribute element).

• Optionally sends an Acknowledge Control Packet to the current Master SM. If it does send one, it awaits a response. If the response is not received, it reports the error to a “higher authority” (i.e., to software).

• Moves to the Master state (by changing its SMInfo.SMState to the Master state).

Not-Active State

Refer to Figure 30-7 on this page. When a SM is in the Not-Active state, it does not send SubnGet(SMInfo) or SubnSet(SMInfo) SMPs. However, it must respond to any SubnGet() or SubnSet() SMPs it may receive. If it receives a Control Packet from the Master SM commanding it to go to the Standby state, it must do so.