Ethernet Ring Protection Switching Protocol

ERPS Topology

The ERPS ring network protection technology works by implementing primary and backup paths in an Ethernet ring topology. The primary path is the usual route for data transmission, while the backup path remains idle, ready to take over in case of failure.

First, we need to create an Ethernet ring network where each network node is connected in a circular manner. Data is transmitted in one direction, passing through each participant until it reaches the destination. The transmission of control traffic, necessary for ERPS operation, is carried out through the R-APS VLAN, which is assigned to each ring. Traffic VLANs that need to be protected from loops and breaks are grouped into special instances called protected VLANs. Also, for each port in the ring, one of three possible roles must be selected: RPL owner, RPL neighbor, or common.

The RPL owner should be one per ring and, under normal conditions, is responsible for blocking loops and unlocking the channel in case of a break. In the diagram above, these are switches A and B.

The RPL neighbor must be on the other side of the link from the RPL owner, and it can also participate in blocking/unblocking the channel. The common port is a regular port that is part of the ring, through which control traffic passes in the R-APS VLAN. According to the G.8032/Y.1344 standard, convergence time should not exceed 50 ms when there are no more than 16 nodes in the ring. As we can see, this time is much shorter than the widely used Spanning Tree protocol.

How ERPS Works

So, we have prepared the ERPS network topology. Now let’s look at what happens in various situations. Let’s start with the normal operation of the network. When there are no breaks failures in the network, signaling messages "No Request" circulate around the ring. In this mode, the RPL owner port is blocked, and the "Node State" is in the "IDLE" state.

Let's make the situation more interesting: a link failure occurred between RPL common. In this case, the switches that detected the link failure, after the "Hold Off Timer" expires, send "Signal Failing" packets.

Other switches that received the "Signal Failing" packet clear their MAC address tables, essentially starting to rebuild the topology. When the RPL owner and RPL neighbour switches receive the "Signal Failing" packet, they unblock the corresponding ports and also clear the MAC address table. Then the switches receive the second "Signal Failing" (from the second switch that detected the link failure in the ring) and again clear the MAC address table. "Node State" is in the "PROTECTION" state.

As a result, the network continues to function, but the ring topology remains broken.

If the switches detect link recovery, they start the "Guard Timer" and begin sending "No Request" packets. Switches that received the "No Request" packet clear the MAC address table again. The switch, which is the RPL owner, starts another timer, the "WTR Timer." Once the "Guard Timer" expires, one of the two switches that detected the link recovery will receive a "No Request" message with a Node ID greater than its own value and unblock the port that was recovered.

If the "revertive mode" value is set to "revertive," then after the "WTR Timer" expires, the switch, one of whose ports is the RPL owner, sends the "No request, RPL blocked" packet and blocks the RPL owner port. After this, the second switch, which detected the link recovery, unblocks its port, and the ring returns to the initial "IDLE" state.

A situation is also possible where the break occurs between the RPL owner and RPL neighbour ports. In this case, the switches start sending the "Signal Failing, Do not Flush" packet. Upon receiving such a message, the other switches will not clear the MAC address table.

The recovery process here will be similar to the recovery of the channel between RPL common, except that in this case, the "Do Not Flush" flag is set, and the switches do not clear the MAC address table.

What factors should be considered when designing ERPS networks?

When designing ERPS networks, several factors must be taken into account to ensure optimal performance and reliability. First and foremost, consider the network's bandwidth requirements and choose the appropriate channel bandwidths. Evaluate the traffic type and expected data transfer speeds to determine the necessary channel bandwidth for each segment of the ring.

Also, evaluate the desired fault detection and recovery time for your network. ERPS provides fast fault detection and recovery, but it is important to determine the acceptable downtime for your specific application and design the network accordingly.

Forecast future growth and scalability of the network. Make sure that the network design can accommodate additional nodes or increased traffic volume without compromising performance or fault tolerance.

Also, consider the management and monitoring capabilities needed for the ERPS network. Evaluate the availability of network management tools and protocols that support ERPS and ensure that they meet your operational requirements.

Network equipment compatibility with ERPS is of great importance. Ensure that switches, routers, and other network devices support the protocols and standards of ERPS to provide seamless integration and functionality.

Conclusion

The ERPS protocol is an important protocol that enhances the reliability and fault tolerance of Ethernet ring networks. By using primary and backup channels, the Ethernet Ring Protection Switching (ERPS) protocol offers significant advantages over the traditional Spanning Tree Protocol (STP) in terms of fast fault detection and ensuring uninterrupted traffic forwarding during network failures. ERPS guarantees continuous data transmission and minimizes downtime. The benefits of ERPS, including fault tolerance, fast network convergence, simplified network management, cost-effectiveness, and seamless integration with existing infrastructure, make it a valuable solution for various applications. One disadvantage of ERPS is that, unlike STP, it requires the use of a ring network topology for its operation.

In general, the ERPS protocol can be used in various industries, from industrial networks and critical infrastructure to small urban and corporate networks.