Export PDFWhat Is ERPS?
Ethernet Ring Protection Switching (ERPS) is a protocol defined by the International Telecommunication Union – Telecommunication Standardization Sector (ITU-T) to prevent loops at Layer 2. ERPS is also called G.8032 because its standard number is ITU-T G.8032/Y.1344. It defines the ring automatic protection switching (R-APS) messages and protection switching mechanism.
Why Do We Need ERPS?
Redundant links (such as those on a ring network) are usually used on an Ethernet switched network to provide link backup and improve network reliability. The use of redundant links, however, may cause loops on the network, leading to broadcast storms and unstable MAC address entries. As a result, the communication quality deteriorates, and communication services may even be interrupted.
As a standard loop prevention protocol defined by the ITU-T, ERPS overcomes the disadvantages of STP, RSTP, and MSTP. ERPS provides fast convergence, meets carrier-class reliability requirements, and supports multiple networking modes. It has good compatibility and allows the device to communicate with devices from other vendors. Therefore, ERPS is widely used on Layer 2 ring networks.
Comparison of ERPS and Other Ring Network Protocols
Ring Network Protocol |
Advantage |
Disadvantage |
|---|---|---|
RRPP |
RRPP provides fast convergence, which meets carrier-class reliability requirements. |
|
STP, RSTP, and MSTP |
|
STP, RSTP, and MSTP provide slow convergence, which is affected by the network size and cannot meet carrier-class reliability requirements. |
SEP |
|
SEP is a Huawei proprietary protocol that cannot allow the device to communicate with devices from other vendors. |
ERPS |
|
The network topology needs to be planned in advance, and the configuration is complex. |
Basic Concepts of ERPS
ERPS prevents loops at the Ethernet link layer. ERPS works for ERPS rings. It blocks the ring protection link (RPL) owner port and controls other common ports to switch the port status between Forwarding and Discarding to eliminate loops. There are two versions of ERPS: ERPSv1 and ERPSv2. ERPSv2 is fully compatible with ERPSv1 and extends ERPSv1 functions.
In the following figure, DeviceA through DeviceD constitute a ring and are connected to the upstream network. This connection mode will cause a loop on the entire network. To eliminate loops on the network and ensure link connectivity, a loop prevention mechanism needs to be used. ERPS can be deployed on the network shown in the following figure. The following describes basic concepts of ERPS based on the figure.
ERPS single-ring networking
ERPS Ring
An ERPS ring consists of connected Layer 2 switching devices that are configured with the same control VLAN. An ERPS ring is the basic unit of ERPS. An ERPS ring can be a major ring or a sub-ring. By default, an ERPS ring is a major ring. A major ring is a closed ring, whereas a sub-ring is an open ring. Both of them are configured using commands. On the network shown in the following figure, DeviceA through DeviceD constitute a major ring, and DeviceC through DeviceF constitute a sub-ring. Only ERPSv2 supports sub-rings, while ERPSv1 does not.
ERPS major ring and sub-ring networking
ERPS Port
RPL owner port
An RPL owner port is manually specified. Once specified, it is blocked to prevent loops on the ERPS ring where it resides. An ERPS ring has only one RPL owner port. When the device where the RPL owner port resides receives a message indicating a node or link fault on the ERPS ring, the device unblocks the RPL owner port so that the port resumes sending and receiving traffic, thus ensuring nonstop traffic forwarding. The link where the RPL owner port resides is the RPL.
RPL neighbour port
An RPL neighbour port is directly connected to an RPL owner port. The RPL neighbour port reduces the number of FDB entry updates on the device where the RPL neighbour port resides. Both the RPL owner port and RPL neighbour port are blocked to prevent loops under normal circumstances, and are unblocked if the ERPS ring fails.
Common port
In an ERPS ring, all ports except the RPL owner port and RPL neighbour port are common ports. A common port monitors the status of the directly connected ERPS link and sends messages to notify the other ports of link status changes.
Forwarding: In this state, the port forwards user traffic and sends and receives R-APS PDUs.
Discarding: In this state, the port does not forward user traffic, but can send and receive R-APS PDUs.
VLAN
ERPS has two types of VLANs: data VLAN and control VLAN. A data VLAN is used to transmit data packets, and a control VLAN is used to transmit R-APS PDUs. Each ERPS ring must be configured with a control VLAN. After a port is added to an ERPS ring configured with a control VLAN, the port is automatically added to the control VLAN. Different ERPS rings cannot be configured with the same control VLAN.
ERP Instance
On a Layer 2 device running ERPS, the VLANs in which R-APS PDUs and data packets are transmitted must be mapped to an Ethernet Ring Protection (ERP) instance so that ERPS forwards or blocks these packets based on blocking rules. If the VLAN is not mapped to an ERP instance, a broadcast storm may occur on the ring network, causing the ring network to become unavailable.
Timers
Guard timer
After a faulty link or node recovers or a clear operation is performed, the device sends R-APS No Request (NR) messages to notify other devices of the link or node recovery and starts the Guard timer. Before the Guard timer expires, the device does not process any R-APS NR message to avoid receiving out-of-date R-APS NR messages. If the device still receives an R-APS NR message after the timer expires, the local port enters the Forwarding state.
WTR timer
If a device or link fails, the RPL owner port is unblocked. After the fault is rectified, the faulty port may have not changed from down to up. To prevent network flapping caused by immediate blocking of the RPL owner port, the device starts the WTR timer after the RPL owner port receives an R-APS NR message. If the device receives an R-APS Signal Failed (SF) message before the WTR timer expires, the device disables the WTR timer and does not block the RPL owner port. If the device does not receive any R-APS SF message before the WTR timer expires, the device blocks the RPL owner port when the WTR timer expires and sends an R-APS No Request RPL Blocked (NRRB) message. After receiving the R-APS NRRB message, the other ports set their forwarding status to Forwarding.
Holdoff timer
Layer 2 networks running ERPS may have different requirements on the protection switching sequence. For example, if a server fails on a network that provides multi-layer services, users may require a period of time to restore the server, during which clients are unaware of the fault. That is, protection switching is not performed immediately. You can set a proper Holdoff timer value. If a fault occurs, the fault is not immediately reported to ERPS. Instead, the fault is reported only when the Holdoff timer expires and the fault persists.
WTB timer
When the switching status (Forced Switch or Manual Switch) of a port is cleared, the WTB timer is started. Because multiple ports on an ERPS ring may be manually blocked, the clear operation takes effect only after the WTB timer expires. This prevents the RPL owner port from being blocked immediately.
The WTB timer cannot be manually specified but depends on the Guard timer configuration. The value of the WTB timer is the value of the Guard timer plus 5s. The default value of the WTB timer is 7s.
Revertive and Non-revertive Switching Modes
After a link fault on an ERPS ring is rectified, re-blocking the RPL owner port depends on the configured revertive or non-revertive switching mode.
- In revertive switching mode, if the faulty link recovers, the RPL owner port is re-blocked after the WTR timer expires. The blocked link is switched back to the RPL.
- In non-revertive switching mode, if the faulty link recovers, the WTR timer is not started and the original faulty link is still blocked.
By default, an ERPS ring works in revertive switching mode.
ERPSv1 supports only revertive switching mode, whereas ERPSv2 supports both revertive and non-revertive switching modes.
Port Blocking Modes
- FS: A port configured with FS is immediately blocked regardless of whether other links on the ring are faulty.
- MS: The process of performing an MS operation on a port on an ERPS ring is similar to that of performing an FS operation on a port. The difference is that the MS operation does not take effect if the ERPS ring is not in Idle or Pending state.
- Clears the local MS and FS configurations.
- Triggers revertive switching before the WTB or WTR timer expires when the ERPS ring is in revertive switching mode.
- Triggers revertive switching when the ERPS ring is in non-revertive switching mode.
Only ERPSv2 supports port blocking modes, whereas ERPSv1 does not.
R-APS PDU Transmission Mode in a Sub-ring
ERPSv2 supports single-ring and multi-ring topologies. In multi-ring topologies, R-APS PDUs from sub-rings can be transmitted in virtual channel (VC) and non-virtual channel (NVC) modes.
- VC mode: R-APS PDUs from a sub-ring are transmitted to the major ring through interconnected nodes. That is, interconnected nodes do not terminate R-APS PDUs from a sub-ring. A blocked port on the sub-ring blocks both R-APS PDUs and data traffic on the sub-ring.
- NVC mode: R-APS PDUs from a sub-ring are terminated on interconnection nodes. A blocked port on the sub-ring blocks data traffic but not R-APS PDUs on the sub-ring.
On the network shown in the following figure, a major ring is interconnected with two sub-rings. The sub-ring on the left transmits R-APS PDUs in VC mode, and the sub-ring on the right transmits R-APS PDUs in NVC mode.
Interconnected rings using VC and NVC modes
By default, R-APS PDUs from a sub-ring are transmitted in NVC mode. In a special networking scenario shown in the following figure where sub-ring links are discontinuous, the VC mode must be used. In other scenarios, the default NVC mode is recommended. On the network shown in the following figure, links b and d belong to major rings 1 and 2 respectively, and links a and c belong to a sub-ring. Links a and c are independent of each other and cannot detect the status change of each other. Therefore, VCs must be used to transmit R-APS PDUs.
Network diagram of a special scenario where virtual channels are used
R-APS PDU Transmission Mode in a Sub-ring |
Advantage |
Disadvantage |
|---|---|---|
VC |
This mode can be used in special scenarios where virtual channels are used. |
R-APS virtual channels on a sub-ring are affected by the topology of adjacent rings. Resources need to be reserved and control VLAN IDs need to be allocated for R-APS virtual channels on the network where these virtual channels reside. |
NVC |
This mode does not require resource reservation and control VLAN ID assignment from adjacent rings. |
This mode cannot be used in special scenarios where virtual channels are used. |
ERPSv1 and ERPSv2
Function |
ERPSv1 |
ERPSv2 |
|---|---|---|
Ring creation |
Only a single ring can be created. Sub-rings cannot be configured. |
Multiple rings can be created, that is, major rings and sub-rings can be configured. |
Port role configuration |
The RPL owner port and common ports can be configured. |
The RPL owner port, the RPL neighbour port, and common ports can be configured. |
Topology change notification |
This function is not supported. |
This function is supported. |
Transmitting R-APS PDUs from sub-rings in VC and NVC modes |
This function is not supported. |
This function is supported. |
Revertive and non-revertive switching mode |
The revertive switching mode is used by default and cannot be configured. The non-revertive switching mode is not supported. |
Both the revertive switching and non-revertive switching modes can be configured. |
Manually switching blocked ports |
This function is not supported. |
This function is supported. Both FS and MS modes are supported. |
ERPSv2 is fully compatible with ERPSv1. If all devices on an ERPS ring support both ERPSv1 and ERPSv2, configuring ERPSv2 is recommended.
R-APS PDUs
ERPS protocol packets are called ring automatic protection switching (R-APS) protocol data units (PDUs). R-APS PDUs contain ERPS ring information and are transmitted on ERPS rings to exchange port information between devices. Figure 1-6 shows the basic R-APS PDU format.
The following table describes the fields in an R-APS PDU.
Field |
Length |
Description |
|---|---|---|
MEL |
3 bits |
Indicates the maintenance entity group (MEG) level. |
Version |
5 bits |
|
OpCode |
8 bits |
Indicates that the PDU is an R-APS PDU. This field has a fixed value of 0x28. |
Flags |
8 bits |
This field has a fixed value of 0x00. It is ignored during packet receiving. |
Type-length-value (TLV) Offset |
8 bits |
Indicates that the TLV starts after an offset of 32 bytes. This field has a fixed value of 0x20. |
R-APS Specific Information |
32 x 8 bits |
Carries ERPS ring information. This field is the core field in an R-APS PDU. ERPSv1 and ERPSv2 differ in some sub-fields of this field. |
TLV |
Unlimited |
Describes information to be loaded. The End TLV has a fixed value of 0x00. |
Format of the R-APS Specific Information field in ERPSv1
Format of the R-APS Specific Information field in ERPSv2
Field |
Length |
Description |
|---|---|---|
Request/State |
4 bits |
Indicates that this R-APS PDU is a request or state PDU. The value can be:
|
Reserved 1 |
4 bits |
In ERPSv1, this field is Reserved 1, indicating that it is reserved for subsequent packet response or protection type identification.
In ERPSv2, this field is Sub-code.
|
Sub-code |
||
Status |
8 bits |
Includes the following status information:
|
Node ID |
6 x 8 bits |
Indicates the MAC address of a node on an ERPS ring. This field is informational and does not affect protection switching on the ERPS ring. |
Reserved 2 |
24 x 8 bits |
Reserved field. This field is set to all 0s during R-APS PDU sending and is ignored during R-APS PDU receiving. |
ERPS Single-Ring
ERPS is a standard ring network protocol used to prevent loops on an ERPS ring at the Ethernet link layer. To prevent loops on an ERPS ring, you can enable the loop prevention mechanism to block the RPL owner port to eliminate loops. If a link on the ring network fails, the device running ERPS immediately unblocks the blocked port and performs link protection switching to restore communication between nodes on the ring network. In an ERPS single-ring scenario, only one ERPS ring is configured on an ERPS network. Both ERPSv1 and ERPSv2 support ERPS single-ring.
This section describes how ERPS is implemented on a single-ring network when links are normal, when a link fails, and when the link recovers (including protection switching operations).
Normal Links
- To prevent loops, ERPS blocks the RPL owner port and also the RPL neighbour port (if any). Other ports can forward service traffic.
- The RPL owner port on the ERPS ring sends R-APS NRRB messages to other nodes on the ring at an interval of 5s, indicating that ERPS links are normal.
ERPS single-ring networking (normal links)
Link Fault
In the following figure, if the link between DeviceD and DeviceE fails, the ERPS protection switching mechanism is triggered. The ports on both ends of the faulty link are blocked, and the RPL owner port and RPL neighbour port are unblocked to send and receive user traffic, ensuring uninterrupted traffic forwarding. The detailed process is as follows:
- After DeviceD and DeviceE detect the link fault, they block their ports on the faulty link and update their FDB entries.
- DeviceD and DeviceE send three consecutive R-APS SF messages carrying local link fault information to the other devices and then send R-APS SF messages at an interval of 5s.
- After receiving R-APS SF messages, the other devices update their FDB entries. After receiving R-APS SF messages, DeviceC (where the RPL owner port resides) unblocks the RPL owner port and updates its FDB entries. Similarly, after receiving R-APS SF messages, DeviceB (where the RPL neighbour port resides) unblocks the RPL neighbour port and updates its FDB entries.
ERPS single-ring networking (link fault)
Link Recovery
After the faulty link recovers, if the ERPS ring uses the revertive switching mode, the device where the RPL owner port resides blocks the RPL again, and the link that has recovered is used to forward traffic. If the ERPS ring uses the non-revertive switching mode, the link that has recovered is still blocked, and the RPL is not blocked. The following uses the revertive switching mode as an example to describe the recovery process:
- After the link between DeviceD and DeviceE recovers, DeviceD and DeviceE start the Guard timer to prevent them from receiving out-of-date R-APS NR messages. They do not receive any R-APS NR messages before the Guard timer expires. At the same time, DeviceD and DeviceE send R-APS NR messages.
- After receiving R-APS NR messages, DeviceC on which the RPL owner port resides starts the WTR timer. After the WTR timer expires, DeviceC blocks the RPL owner port and sends R-APS NRRB messages.
- After receiving R-APS NRRB messages from DeviceC, DeviceD and DeviceE unblock their blocked ports, stop sending R-APS NR messages, and update their FDB entries. After receiving R-APS NRRB messages from DeviceC, the other devices update their FDB entries.
ERPS Multi-Ring
In an ERPS multi-ring scenario, multiple ERPS rings are configured on an ERPS network. ERPSv1 supports only single-ring topologies, whereas ERPSv2 supports both single-ring and multi-ring topologies. An ERPS multi-ring network consists of one or more major rings and sub-rings. R-APS PDUs from sub-rings can be transmitted in VC or NVC mode, depending on whether the R-APS PDUs enter the major ring.
This section describes how ERPS is implemented on a multi-ring network where R-APS PDUs from sub-rings are transmitted in NVC mode when links are normal, when a link fails, and when the link recovers.
Normal Links
In the following figure, DeviceA through DeviceE constitute a major ring. DeviceB, DeviceC, and DeviceF constitute sub-ring 1, and DeviceC, DeviceD, and DeviceG constitute sub-ring 2. The devices on each ring can communicate with each other.
- To prevent loops, each ring blocks its RPL owner port.
- The RPL owner port on the major ring sends R-APS NRRB messages to other nodes on the major ring at an interval of 5s. Similarly, the RPL owner ports on sub-rings 1 and 2 send R-APS NRRB messages to other nodes on their respective rings at an interval of 5s. The R-APS PDUs of the major ring are transmitted only on the major ring. The R-APS PDUs of the two sub-rings are terminated on the interconnected nodes and are not transmitted to the major ring.
Traffic exchanged between PC1 and the upstream network is transmitted along the path PC1 <-> DeviceF <-> DeviceB <-> DeviceA <-> Router1, and traffic exchanged between PC2 and the upstream network is transmitted along the path PC2 <-> DeviceG <-> DeviceD <-> DeviceE <-> Router2.
ERPS multi-ring networking (normal links)
Link Fault
In the following figure, if the link between DeviceD and DeviceG fails, the ERPS protection switching mechanism is triggered. The ports on both ends of the faulty link are blocked, and the RPL owner port on sub-ring 2 is unblocked to send and receive traffic. User traffic of PC1 is not affected. To ensure that downlink traffic of PC2 is not interrupted, interconnected nodes DeviceC and DeviceD need to notify the other nodes on the major ring of the topology change on sub-ring 2. Traffic exchanged between PC2 and the upstream network is transmitted along the path PC2 <-> DeviceG <-> DeviceC <-> DeviceB <-> DeviceA <-> DeviceE <-> Router2. The detailed process is as follows:
- After DeviceD and DeviceG detect the link fault, they block their ports on the faulty link and update their FDB entries.
- DeviceG sends three consecutive R-APS SF messages carrying local link fault information within sub-ring 2 immediately after detecting the link fault and then sends R-APS SF messages at an interval of 5s.
- DeviceG where the RPL owner port resides unblocks the RPL owner port and updates its FDB entries.
- After the interconnected node DeviceC receives R-APS SF messages, it updates its FDB entries. After detecting the topology change, DeviceC and DeviceD send R-APS Event messages within the major ring to notify the other nodes of the topology change on sub-ring 2.
- After receiving R-APS Event messages, the other nodes on the major ring update their FDB entries.
ERPS multi-ring networking (link fault)
Link Recovery
After the faulty link recovers, if the ERPS rings use the revertive switching mode, the device where the RPL owner port resides blocks the RPL again, and the link that has recovered is used to forward traffic. If the ERPS rings use the non-revertive switching mode, the link that has recovered is still blocked, and the RPL is not blocked. The following uses the revertive switching mode as an example to describe the recovery process:
- After the link between DeviceD and DeviceG recovers, DeviceD and DeviceG start the Guard timer to avoid receiving out-of-date R-APS PDUs. They do not receive any R-APS PDUs before the timer expires. At the same time, DeviceD and DeviceG send R-APS NR messages within sub-ring 2.
- DeviceG where the RPL owner port resides starts the WTR timer. After the WTR timer expires, DeviceG blocks the RPL owner port and unblocks its port on the link that has recovered. At the same time, DeviceG sends R-APS NRRB messages.
- After receiving R-APS NRRB messages from DeviceG, DeviceD unblocks its blocked port, stops sending R-APS NR messages, and updates its FDB entries. After receiving R-APS NRRB messages from DeviceG, DeviceC also updates its FDB entries.
- After DeviceC and DeviceD update their FDB entries, they send R-APS Event messages within the major ring to notify the other nodes of the topology change on sub-ring 2.
- After receiving R-APS Event messages, the other nodes on the major ring update their FDB entries.
Finally, the user traffic of PC2 is switched back to the original path.
ERPS Fast Detection
ERPS fast detection allows you to configure the fast detection mode on an ERPS network to implement high-performance protection switching. ERPSv1 does not support this mode. ERPSv2 supports this mode in basic single-ring networking and sub-ring NVC scenarios.
In ERPS fast detection mode, the device where the RPL owner port resides continuously sends bidirectional detection packets to the network to implement millisecond-level fault detection in a single-ring scenario; the edge node sends detection packets to devices on the sub-ring in a multi-ring scenario. If a link fault occurs on a device, the port that is expected to receive detection packets receives an interrupt reported by the hardware to detect the fault and then quickly performs protection switching.
This section describes how ERPS fast detection is implemented when links are normal, when a link fails, and when the link recovers.
Single-Ring Scenario
- Normal Links
In the following figure, DeviceA through DeviceD constitute an ERPS ring network, and all devices are in the Idle state. DeviceA (the device where the RPL owner port resides) periodically sends detection packets in both directions (Direction_W and Direction_E) through the two ERPS member ports on the ring. The two ERPS member ports of other devices on the ring can receive the packets and forward the packets through adjacent ports. The packets are then sent back to DeviceA.
ERPS single-ring networking - Link Fault
When DeviceB's port connected to DeviceC fails, DeviceA and DeviceB in the Direction_E direction and DeviceC, DeviceD, and DeviceA in the Direction_W direction receive timeout events so that the devices can rapidly detect the fault. In this case, the RPL owner port on DeviceA is unblocked, MAC address entries are updated, and traffic sending and receiving are restored. This ensures that traffic is not interrupted.
- Link Recovery
When DeviceB's port connected to DeviceC recovers, all devices receive detection packets properly. After the WTR timer expires, DeviceA configured with the RPL owner port sends detection packets to trigger a revertive switching event so that the devices can quickly detect the fault recovery. In this case, the RPL owner port on DeviceA is blocked.
ERPS fast detection improves only the protection switching performance of devices, but does not affect the ERPS status of devices and ports.
Multi-Ring Scenario
- Normal Links
In the following figure, DeviceA through DeviceD constitute an ERPS major ring, and DeviceC through DeviceF constitute an ERPS sub-ring.
All devices on the major ring and sub-ring are in the Idle state. DeviceC and DeviceD periodically send detection packets in two directions (Direction_W and Direction_E) through the specified ERPS sub-ring edge ports. The two ERPS member ports of other devices on the ring can receive the packets and forward the packets through adjacent ports. Finally, the packets in the Direction_E direction are received and terminated by the sub-ring edge port of DeviceD, and the packets in the Direction_W direction are received and terminated by the sub-ring edge port of DeviceC.
ERPS multi-ring networking - Link Fault
When DeviceD's port connected to DeviceE fails, DeviceD in the Direction_E direction and DeviceE, DeviceF, and DeviceC in the Direction_W direction receive timeout events so that the devices can rapidly detect the fault. In this case, the RPL owner port on DeviceE and the RPL neighbor port on DeviceF are unblocked, MAC address entries are updated, and traffic sending and receiving are restored. This ensures that traffic is not interrupted.
- Link Recovery
When DeviceD's port connected to DeviceE recovers, all devices receive detection packets properly. After the WTR timer expires, DeviceE configured with the RPL owner port sends detection packets to trigger a revertive switching event so that the devices can quickly detect the fault recovery. In this case, the RPL owner port on DeviceA is blocked.
ERPS fast detection improves only the protection switching performance of devices, but does not affect the ERPS status of devices and ports.
- Author： Zhu Yue
- Updated on： 2026-01-13
- Views： 700
- Average rating：
