ERPS Multi-ring Principles
Ethernet Ring Protection Switching Version 1 (ERPSv1) supports only single-ring topology, whereas ERPSv2 supports single-ring and multi-ring topologies.
In a multi-ring topology, there are major rings and sub-rings. Depending on whether Ring Auto Protection Switching Protocol Data Units (R-APS PDUs) on a sub-ring are transmitted to a major ring, a sub-ring can either have or not have a virtual channel (VC). If R-APS PDUs on a sub-ring are transmitted to a major ring, the sub-ring has a virtual channel; otherwise, the sub-ring does not have a virtual channel.
This section describes how ERPS is implemented on a multi-ring network when links are normal, when a link fails, and when the link recovers.
Sub-rings Do Not Have VCs
Links Are Normal
On the multi-ring network shown in Figure 12-11, SwitchA through SwitchE constitute a major ring; SwitchB, SwitchC, and SwitchF constitute sub-ring 1, and SwitchC, SwitchD, and SwitchG constitute sub-ring 2. The LSWs in each ring can communicate with each other.
- To prevent loops, each ring blocks its RPL owner port. All other ports can transmit service traffic.
- The RPL owner port on each ring sends RAPS (NRRB) messages to all other nodes in the same ring at an interval of 5s. The RAPS (NRRB) messages in the major ring are transmitted only in this ring. The RAPS (NRRB) messages in each sub-ring are terminated on the interconnected nodes and therefore are not transmitted to the major ring.
Traffic between PC1 and the upper-layer network travels along the path PC1 -> SwitchF -> SwitchB -> SwitchA -> Router1; traffic between PC2 and the upper-layer network travels along the path PC2 -> SwitchG -> SwitchD -> SwitchE -> Router2.
A Link Fails
As shown in Figure 12-12, if the link between SwitchD and SwitchG fails, the ERPS protection switching mechanism is triggered. The ports on both ends of the faulty link are blocked, and the RPL owner port in sub-ring 2 is unblocked to send and receive traffic. In this situation, traffic from PC1 still travels along the original path. SwitchC and SwitchD inform the other nodes in the major ring of the topology change so that traffic from PC2 is also not interrupted. Traffic between PC2 and the upper-layer network travels along the path PC2 -> SwitchG -> SwitchC -> SwitchB -> SwitchA -> SwitchE -> Router2. The process is as follows:
- After SwitchD and SwitchG detect the link fault, they block their ports on the faulty link and update Filtering Database (FDB) entries.
- SwitchG sends three consecutive RAPS (SF) messages to the other LSWs and sends one RAPS (SF) message at an interval of 5s afterwards.
- SwitchG then unblocks the RPL owner port and updates FDB entries.
- After the interconnected node SwitchC receives an RAPS (SF) message, it updates FDB entries. SwitchC and SwitchD then send RAPS Event messages within the major ring to notify the topology change in sub-ring 2.
- After receiving an RAPS Event message, the other LSWs in the major ring update FDB entries.
Then traffic from PC2 is switched to a normal link.
The Link Recovers
After the link fault is rectified, either of two situations may occur:
- If the ERPS ring uses revertive switching, the RPL owner port is blocked again, and the link that has recovered is used to forward traffic.
- If the ERPS ring uses non-revertive switching, the RPL remains unblocked, and the link that has recovered is still blocked.
The following example uses revertive switching to illustrate the process after the link recovers.
- After the link between SwitchD and SwitchG recovers, SwitchD and SwitchG start the Guard timer to avoid receiving out-of-date RAPS PDUs. The two devices do not receive any RAPS PDUs before the timer expires. Then SwitchD and SwitchG send RAPS (NR) messages within sub-ring 2.
- SwitchG on which the RPL owner port resides starts the WTR timer. After the WTR timer expires, SwitchG blocks the RPL owner port and unblocks its port on the link that has recovered and then sends RAPS (NR, RB) messages within sub-ring 2.
- After receiving an RAPS (NR, RB) message from SwitchG, SwitchD unblocks its port on the recovered link, stops sending RAPS (NR) messages, and updates FDB entries. SwitchC also updates FDB entries.
- SwitchC and SwitchD (interconnected nodes) send RAPS Event messages within the major ring to notify the link recovery of sub-ring 2.
- After receiving an RAPS Event message, the other LSWs in the major ring update FDB entries.
Then traffic changes to the normal state, as shown in Figure 12-11.
Sub-rings Have VCs
When sub-rings have VCs, the R-APS PDUs of the sub-rings are transmitted to the major ring through the interconnection nodes. In other words, the interconnection nodes do not terminate the R-APS PDUs of the sub-rings. The blocked ports of sub-rings block both R-APS PDUs and data traffic.
Links Are Normal
On the multi-ring network shown in Figure 12-13, Switch A, Switch B, and Switch E constitute major ring 1; Switch C, Switch D, and Switch F constitute major ring 2; Switch A through Switch D constitute a sub-ring. The two major rings are interconnected with the sub-ring. The devices on each ring can communicate with each other.
- To prevent loops, each ring blocks its RPL owner port. All other ports can transmit data traffic.
- The RPL owner port on each ring sends R-APS (NR) messages to all other nodes on the same ring at an interval of 5s. The R-APS (NR) messages of each major ring are transmitted only within the same major ring, whereas the R-APS (NR) messages of the sub-ring are transmitted to the major rings over the interconnection nodes.
Traffic between PC1 and PC2 travels along the path PC1 <-> Switch E <-> Switch B <-> Switch C <-> Switch F <-> PC2.
A Link Fails
As shown in Figure 12-14, if the link between Switch B and Switch C fails, ERPS is triggered. Specifically, the ports on both ends of the faulty link are blocked, and the RPL owner port on the sub-ring is unblocked to send and receive user traffic. Switch B and Switch C inform the other nodes on the major rings of the topology change so that traffic between PCs is not interrupted. Traffic between PC1 and PC2 then travels along the path PC1 <-> Switch E <-> Switch B <-> Switch A <-> Switch D <-> Switch C <-> Switch F <-> PC2. The detailed process is as follows:
- After Switch B and Switch C detect the link fault, they both block their ports on the faulty link and perform an FDB flush.
- Switch B sends three consecutive R-APS (SF) messages to the other devices on the sub-ring and then sends one R-APS (SF) message at an interval of 5s afterwards. The R-APS (SF) messages then arrive at major ring 1.
- After receiving an R-APS (SF) message, Switch A on major ring 1 unblocks its RPL owner port and performs an FDB flush.
- The other major ring nodes also perform an FDB flush. Traffic between PCs is then rapidly switched to a normal link.
The Link Recovers
After the link fault is rectified, either of the following situations may occur:
- If the revertive switching mode is configured for the ERPS major rings and sub-ring, the RPL owner port is blocked again, and the link that has recovered is used to forward traffic.
- If the non-revertive switching is configured for the ERPS major rings and sub-ring, the RPL owner port remains unblocked, but the link that has recovered remains blocked.
The following example uses revertive switching to describe the process after the link recovers.
- After the link between Switch B and Switch C recovers, Switch B and Switch C start a guard timer to avoid receiving out-of-date R-APS PDUs. The two routers do not receive any R-APS PDUs before the timer expires. Then Switch B and Switch C send R-APS (NR) messages, which are transmitted within the major rings and sub-ring.
- Switch A starts the WTR timer. After the WTR timer expires, Switch A blocks the RPL owner port and then sends R-APS (NR, RB) messages to other connected devices.
- After receiving an R-APS (NR, RB) message from Switch A, Switch B and Switch C unblock its port on the recovered link, stop sending R-APS (NR) messages, and perform an FDB flush.
- After receiving an R-APS (NR, RB) message from Switch A, other devices also perform an FDB flush.
Traffic then travels in the same way as that shown in Figure 12-13.