Ring Controller State Machine Global States

The ERFT Ring Mode supports the following eight global states. Ring Controller State Machine - High Level also defines the global states of the ring controller state machine.

1. RESET - This is the start state for the state machine. This state unconditionally resets the hardware and transitions to the WAITING FOR CONFIGURATION state.

2. WAITING FOR CONFIGURATION - Until the host configures the EXNET-ONE card (assigns the EXNET-ONE card to the ring, specifies transmit (TX) mode, number of packets and so forth.), the ring state machine resides in this state. Once the EXNET-ONE card is configured, the host In Service state is checked.

3. OUT OF SERVICE (OOS) - If the host has the ring out of service, the ring state machine waits in this state until the host brings the ring in service.

4. WAITING FOR ADDITION - If the ring state machine resets while the host has the ring In Service, the ring state machine waits in the WAITING FOR ADDITION state until the host passively adds the node to the ring or the master node resets. Only slave nodes enter this state. The master node automatically brings the ring back up.

5. CONNECTING TO RING - When the host brings the ring in service or the master mode resets (bringing down the entire ring), the EXNET-ONE card enters this state to participate on the ring. To the host, this is seen as a single state. Actually, this is a series of sub-states based off of the following factors:

• Whether the EXNET-ONE card is configured as a master or slave node, and is it in a SRR configuration.

• Whether the EXNET-ONE card is taking the role of the active or standby card.

6. RUNNING (INS) - The EXNET-ONE card is connected to the ring. If it is configured to transmit data, the nodes entire payload is transmitted onto the ring (1 or 4 packets). Once the ring is running, the ring state machine interrogates the ring to determine which nodes are transmitting on the ring. The node accessibility information is sent to the Matrix Controller card so that Layer 4 can route calls over the ring. While in this state, the ring is continuously monitored and its health maintained. Different features are supported based off the ring state machine variant.

7. RUNNING FAILURE - When a condition occurs that causes the EXNET ring to lose frame synchronization, the ring state machine enters the RUNING FAILURE state to try and recover the ring.

If the EXNET-ONE card is in the ERFT Ring Mode, the master node re-validates each link until the faulty one is found and looped out of the ring. If the faulty link cannot be found and the ring can not recover, the ring state machine is reset. The standby EXNET-ONE card monitors its node’s packet information on the ring. If the active EXNET-ONE card is removed from the ring, the standby EXNET-ONE card will no longer see itself on the ring and switchover to the active EXNET-ONE card.

8. FAIL - An abnormal condition that causes the ring to reset induces failure processing to be performed. If the EXNET-ONE card cannot recover, or has failed too many times, it transitions to the FAIL state. Until the host brings the ring out of service or successfully runs diagnostics on the EXNET-ONE card, the EXNET-ONE card will not participate on the ring.

Figure 10-14 Ring Controller State Machine - High Level

The ring controller follows the basic state machine and shows primarily how the EXNET-ONE cards connect to the ring and how they recover from a failure described. Every time the EXNET-ONE card changes its ring state, the host is notified with the Ring Status Report (0x72). This API message notifies the host of the EXNET-ONE card’s current status on the EXNET ring. See Ring Status Report (0x72) as an example.

Table 10-5 Ring Status Report (0x72)

A Ring Status Report (0x72) message is also sent whenever the port status or configuration data changes. The Ring Status Report message, however, does not provide the host service state, which node is the master node, and the number of packets. The More Status field along with the Ring Status can be used to determine the current state of the EXNET-ONE card.

SRR Configuration

Follow the steps below to set up the Single Ring Redundancy (SRR):

• Install the second EXNET-ONE card hardware.

• Connect the two EXNET-ONE cards as shown in Single Ring Redundancy EXNET-ONE card Connections.

• For further information, see the Expanding the EXNET Ring (6-38) for instructions on configuring an expanded switching system.

Figure 10-15 Single Ring Redundancy EXNET-ONE card Connections

The SRR feature is enabled by assigning two EXNET-ONE cards to the same Ring ID (API 0x74, Entity 0x01). The first EXNET-ONE card assigned to the ring takes the role of the active EXNET-ONE card; the second EXNET-ONE card assigned to the ring takes the role of the standby card. All subsequent ring configuration messages are applied to both EXNET-ONE cards assigned to the ring, allowing the node to support SRR configurations with little if any host intervention.

No Redundancy (0x00)

Until a redundant EXNET-ONE card is assigned to the ring, the EXNET-ONE card is in the active state (non-SRR). The active EXNET-ONE card knows that it is not in a redundant configuration.

Active (0x01)

Once a redundant EXNET-ONE card is assigned to the ring, one
EXNET-ONE card takes the active state and the other, the standby state. The active EXNET-ONE card still acknowledges a non-redundant configuration, but indicates an awareness of the standby EXNET-ONE card.

Standby (0x02)

The standby EXNET-ONE card, although configured identically as the active EXNET-ONE card, does not transmit on the ring or local PCM bus.

The standby EXNET-ONE card:

• Operates in the Receive Only mode. The participates in initializing the ring as any other Receive Only slave, receiving and processing all of the data from the ring.

• Passes data through from one adjacent EXNET-ONE card to the other.

• Will not intentionally bring down the ring. If the ring is already up, the standby EXNET-ONE card will wait until it can be passively added to the ring.

Undefined (0xFF)

This is a transition state. When a EXNET-ONE card is brought in service (not the ring), the Matrix Controller notifies the EXNET-ONE card of its redundancy state. For the case where the active
EXNET-ONE card resets, a switchover is performed. When the EXNET-ONE card comes back up, it does not know if its current redundancy state is valid. For cases where the EXNET-ONE card resets and was previously defined as either active or standby, it updates its redundancy state to Undefined, waiting until the Matrix Controller updates it. While in this state, the EXNET-ONE card will not participate on the ring. The host should never see a EXNET-ONE card in this state.

The SRR feature is enabled when the host configures a second EXNET-ONE card to a ring. This causes the Matrix Controller to configure a second EXNET-ONE card as the redundant standby and notifies the other EXNET-ONE card that it is active in a redundant configuration.

The Matrix Controller downloads the configuration and connection data of the active EXNET-ONE card to the standby EXNET-ONE card, therefore a EXNET-ONE card can be introduced at anytime. Either before the active EXNET-ONE card is fully configured, halfway in between, afterwards, or even after the ring is brought in service and calls are established. The standby EXNET-ONE card automatically synchronizes itself with the active EXNET-ONE card.

Once the standby EXNET-ONE card is assigned to a ring, all subsequent messages identified by the Ring ID are forwarded to all EXNET-ONE cards assigned to the ring.

Except for assigning the EXNET-ONE card to the ring (EXNET Ring Configure (0x74), Entity Assign Ring), Passive Node Addition, and querying the ring (Ring Status Query 0x71), all ring configuration and maintenance messages can reference the Ring ID. From the position of the host, this allows the ring to be configured the same way whether it is in an SRR or non-SRR configuration. When passively adding the standby EXNET-ONE card or a SRR configured node, both addressing schemes are supported, slot-based, and ring-based. See Passive Additions Process. All messages addressed by the Ring ID are processed by all EXNET-ONE cards assigned to the ring. All messages addressed by the slot number are processed by the individual
EXNET-ONE card, regardless of the ring.

The major impact the SRR plays on the host is the increase of CSP solicited Ring Status Report (0x72) messages. Currently, the EXNET-ONE card sends a Ring Status Report to the host when the following conditions occur:

• The EXNET-ONE card sees the ring as out-of-service (ring status 0xFF)

• The EXNET-ONE card is connected to the ring (ring status 0x01)

• The EXNET-ONE card sees the ring as in service and valid data is being passed (ring status 0x00)

• The EXNET-ONE card detects a port status change (port loops back or opens)

The differences are as follows:

• A report will be sent from both EXNET-ONE cards (number of messages has doubled)

• A report is sent every time a EXNET-ONE card changes its redundancy state

• The redundancy state is supplied

The other impact that the SRR plays on the host is that the Ring Status Query (0x71) now provides the EXNET-ONE cards redundancy state.

Under normal conditions, the Ring Status Report (0x72) received from the standby EXNET-ONE card should match the active EXNET-ONE card. Some fields are common to the ring and some are specific to the EXNET-ONE card:

Ring Common Fields

• Logical Ring ID

• Ring Status

• More Status

• Master Status

• Transmit Mode

• Source Packet Mode

• Master Arbitration Flag

• Ring Mode

EXNET-ONE Card Specific Fields

• Slot Number

• EXNET Port A Status

• EXNET Port B Status

• Redundancy State

If the Ring Common Fields deviate, it indicates that something is abnormal. The only normal deviation is when a standby is introduced while the current status of the ring is in service. For this case, the ring status of the standby EXNET-ONE card should indicate that it is out-of-service. This should trigger the host to passively add to the standby EXNET-ONE card to the ring or display a notice to the operator.