Implementation of Multiple Rings

A multi-ring RRPP network works in almost the same way as a single-ring RRPP network. On a multiple-ring network:

When receiving Common-Flush-FDB or Complete-Flush-FDB packets from a sub-ring, a node on the major ring relearns the entries and updates its forwarding entries. Data flows re-select the path.
A transit node on the major ring unblocks the temporarily blocked interface only when receiving a Complete-Flush-FDB packet sent from the major ring, not from the sub-ring.
The path status detection mechanism for sub-ring protocol packets on the major ring is used on a network with multiple rings. For details, see Path Status Detection Mechanism for Sub-Ring Protocol Packets on the Major Ring.
Ring groups are used to improve system performance. For details, see Ring Group.

Path Status Detection Mechanism for Sub-Ring Protocol Packets on the Major Ring

This mechanism applies to networks where multiple sub-rings intersect with the master ring. It is used to prevent loops among sub-rings after secondary interfaces are unblocked by master nodes on sub-rings.

Figure 1 shows an example of broadcast loops forming between sub-rings, and how the path status detection mechanism can prevent these loops.

Figure 1 Loop formation between sub-rings

When the common link between the major ring and sub-ring is faulty and at least one non-common link is faulty, the master node on each sub-ring unblocks its secondary interface (S in Figure 1) because the secondary interface does not receive Hello packets. In this case, broadcast loops (blue dashed lines in Figure 1) may occur between sub-rings. To prevent loops, the network deploys the path status detection mechanism for sub-ring protocol packets on the major ring. After this mechanism is configured, the edge node and assistant edge node detect the path status. When the edge node detects that the path is interrupted, the edge interfaces on the two sub-rings are blocked before the master nodes on the two sub-rings unblock their secondary interfaces. This prevents loops between sub-rings. The edge interfaces on the edge nodes of sub-ring 1 and sub-ring 2 are blocked, preventing loops. If the edge port is blocked, device connectivity cannot be ensured.

The specific procedure for preventing loops using the path status detection mechanism for sub-ring protocol packets is as follows:

The edge node checks the path status of sub-ring protocol packets on the major ring.

The edge node on a sub-ring periodically sends Edge-Hello packets to the major ring through two RRPP interfaces on the major ring. Edge-Hello packets are transmitted through all transit nodes on the ring. The assistant edge node does not forward the received Edge-Hello packets.

In Figure 2, the edge node sends Edge-Hello packets to the major ring through Interface1 and Interface2, which are also located on the major ring.

Figure 2 Edge node sending Edge-Hello packets

If the assistant edge node receives the Edge-Hello packets within the specified period, the protocol packet path is normal; if the assistant edge node receives no Edge-Hello packets within the specified period, the path is faulty.
The path is disconnected and the edge node blocks the edge interfaces.

Upon detecting that the sub-ring protocol packet path is disconnected, the assistant edge node immediately sends a Major-Fault packet to the edge node. After receiving the Major-Fault packet, the edge node blocks its edge interfaces.

In Figure 3, the assistant node sends a Major-Fault packet to the edge node from Interface3.

Figure 3 Blocking edge interfaces
The master node on the sub-ring unblocks the secondary interface after the Fail timer expires.

After the edge node blocks its edge interfaces, the path for sub-ring protocol packets is disconnected because of the failure on the major ring. As a result, the master node on the sub-ring cannot receive the Hello packet sent by the master node within the specified period. The master node changes to Failed state and unblocks the secondary interface.

In Figure 4, the edge node blocks its edge interfaces. The master node on the sub-ring unblocks the secondary interface that is blocked in Figure 3.

Figure 4 Sub-ring disconnected due to the blocked path on the major ring
The sub-ring protocol packet path recovers.

After the link on the major ring recovers, the communication between the edge node and assistant edge node recovers, and the path for the sub-ring protocol packets is recovered. The secondary interface on the sub-ring can receive the Hello packets sent from the master node. The master node then changes to Complete state and blocks the secondary interface. Figure 5 illustrates this process (recovery of the sub-ring protocol packet path).

Figure 5 Recovery of the sub-ring protocol packet path

In Figure 6, the master node on the sub-ring sends a Complete-Flush-FDB packet. Upon receiving the packet, the edge node unblocks the edge interfaces.

Figure 6 Unblocking the edge interfaces on the edge node of the sub-ring

Ring Group

In RRPP multi-instance, sub-rings are grouped to reduce the number of received and sent Edge-Hello packets, improving system performance.

In the path status detection mechanism for sub-ring protocol packets on the major ring, the edge node on a sub-ring periodically sends Edge-Hello packets to the two RRPP interfaces on the major ring to detect the completeness of the path for sub-ring protocol packets.

In Figure 7, the edge nodes on multiple sub-rings (sub-ring 2 and sub-ring 3 in domain 1; sub-ring 2 and sub-ring 3 in domain 2) are the same device, and the assistant edge nodes on the sub-rings are the same device. In addition, edge nodes and assistant edge nodes connect to the major ring in the same link. The Edge-Hello packets from edge nodes on the sub-rings arrive at assistant edge nodes along the same path. In this case, the sub-rings that have the same edge nodes and assistant edge nodes can be added into a ring group. A sub-ring in the ring group is selected to send Edge-Hello packets to detect the path for sub-ring protocol packets on the major ring. This reduces the number of received and sent Edge-Hello packets and improves system performance.

Figure 7 Ring group in RRPP multi-instance

A sub-ring in the ring group is selected to send the Edge-Hello packet in the following procedure:

The sub-rings with the smallest domain ID are selected from all the activated rings in the ring group on the edge node. In Figure 7, the sub-rings with the smallest domain ID are ring 2 in domain 1 and ring 3 in domain 1.
The smallest ring ID is selected from the rings with the smallest domain ID. The edge node on the ring with the smallest ring ID then sends Edge-Hello packets. In Figure 7, the sub-ring with the smallest ring ID is Ring 2 in Domain 1. Therefore, the edge node on Ring 2 in Domain 1 sends Edge-Hello packets in the ring group formed by ring 2 in domain 1, ring 3 in domain 1, ring 2 in domain 2, and ring 3 in domain 2.
When any sub-ring receives an Edge-Hello packet on all the activated rings in the ring group where assistant edge nodes reside, the sub-ring notifies other sub-rings of the packet.