RRPP Technology White Paper

Keywords: RRPP, RRPP domain, RRPP ring, control VLAN, protected VLAN, master node, transit node, edge node, assistant-edge node, ring group.

Abstract: The Rapid Ring Protection Protocol (RRPP) is a link layer protocol dedicated to Ethernet rings. This document introduces H3C’s RRPP implementation, characteristics, and typical networking schemes.

Acronyms:

Acronym

Full spelling

RRPP

Rapid Ring Protection Protocol

SRPT

Sub Ring Packet Tunnel in Major Ring

STP

Spanning Tree Protocol

VLAN

Virtual Local Area Network

 

 



Overview

1.1  Background

Nowadays, most networks use the ring structure to improve reliability. With ring networking technologies, network devices are connected to form rings. To avoid broadcast storms, which are common in a ring network, a loop protection mechanism must be used.

The IEEE spanning tree protocols have been widely used for loop protection. However, as STP topology convergence gets slower while network size is growing, transmission performance can be degraded in a large network.

To remove the negative impact of network size on topology convergence and shorten topology convergence time, H3C developed RRPP.

1.2  Benefits

RRPP is a link layer protocol dedicated to Ethernet rings. It can prevent broadcast storms caused by data loops when an Ethernet ring is healthy, and rapidly restore the communication paths between the nodes after a link is disconnected on the ring by bringing up the backup link.

Compared with STP, RRPP has the following advantages:

l              Fast topology convergence within 50 ms.

l              Convergence time independent of Ethernet ring size.

On intersecting rings, the topology change of an RRPP ring does not cause topology changes in the other rings, and therefore, data transmission is more stable. In addition, RRPP supports load sharing in Ethernet rings, which improves physical link bandwidth utilization.

RRPP Implementation

2.1  Basic Concepts in RRPP

2.1.1  RRPP Domain

An RRPP domain identified by an integral ID defines a topology range calculated and controlled by the RRPP protocol. It consists of some interconnected devices with the same domain ID, control VLANs, and protected VLANs. A device can belong to multiple RRPP domains.

An RRPP domain consists of the following elements:

l              RRPP rings

l              RRPP control VLANs

l              RRPP protected VLANs

l              Master nodes

l              Transit nodes

l              Edge nodes

l              Assistant-edge nodes

In Figure 1, Domain 1 is an RRPP domain that contains Ring 1 and Ring 2 formed by devices S1 through S6. Ring 1 is the primary ring, where S1 is the master node and S2, S3, and S4 are transit nodes. Ring 2 is the subring, where S6 is the master node, and S5 is a transit node. S3 and S2 are the edge node and the assistant-edge node respectively. The primary control VLAN and secondary control VLAN of Domain 1 are VLAN 3 and VLAN 4 respectively.

Figure 1 A sample RRPP domain

2.1.2  RRPP Ring

Each RRPP ring corresponds to a ring-shaped Ethernet topology and is identified by an integral ID. As described in the last section, an RRPP domain consists of a single RRPP ring or multiple connected RRPP rings. The topology calculation is actually based on RRPP rings.

Typically, ring topologies fall into these three types: single ring, tangent rings, and intersecting rings. For each topology type, the RRPP domain configuration is different:

l              All devices on the single ring are configured to be in the same RRPP domain.

l              All devices on intersecting rings are also configured to be in the same RRPP domain.

l              For two tangent rings, the devices on each ring are configured to be in the same RRPP domain. That is, two tangent rings need two different RRPP domains, one for each ring.

In an RRPP domain with intersecting rings, to achieve independent topology calculation on each ring without affecting other rings and prevent loops, you need to configure one ring as the primary ring and the others as subrings. The primary ring as a whole serves as a logical node on the subrings, and protocol packets from the subrings are transparently transmitted through the primary ring. In this way, topology calculation is performed on the intersecting rings as a whole. Protocol packets of the primary ring are confined within the primary ring. The level of the primary ring is 0 and that of subrings is 1.

For example, to configure Ring 1 in Figure 1 as the primary ring, you should set its ring level to 0 and set the level of all the other rings in the domain, Ring 2 in this example, to 1. By doing this, you can prevent loops in the intersecting ring topology and ensure the connectivity between nodes.

2.1.3  RRPP Control VLAN

As described earlier, RRPP separates data traffic from RRPPDUs (RRPP packets) by transmitting RRPPDUs in dedicated VLANs called control VLANs. An RRPP domain is configured with one primary control VLAN and one secondary control VLAN. After you specify a VLAN as the primary control VLAN, the VLAN whose ID is one plus the primary control VLAN ID is configured as the secondary control VLAN automatically. The primary control VLAN transmits the RRPPDUs of the primary ring and the EDGE-HELLO messages of the subrings. The secondary control VLAN transmits the RRPPDUs of the subrings except the EDGE-HELLO messages.

All the ports connecting devices to RRPP rings are assigned to control VLANs, and only such ports can be assigned to control VLANs. As shown in Figure 1, 3 and/or 4 near a port indicate the VLAN(s) the port is assigned to. RRPP ports on the primary ring must be assigned to both the primary control VLAN and the secondary control VLAN; RRPP ports on the subrings can be assigned to only the secondary control VLAN.

2.1.4  RRPP Protected VLAN

A protected VLAN is a VLAN that transmits data packets. It can contain both RRPP ports and non-RRPP ports. A protected VLAN’s forwarding status is controlled by its RRPP domain. Different RRPP domains on the same RRPP ring are configured with different protected VLANs, and each RRPP domain controls the forwarding status of ports in it independently.

2.1.5  Master Node

Each device on an RRPP ring is called an RRPP node. On an RRPP ring, you must configure only one as the master node. The master node initiates ring status detection with the polling mechanism and makes operation decisions upon ring topology changes. In Figure 1, S1 is the master node on the primary ring, and S6 is the master node on the subring.

A master node can be in one of the following states:

l              Complete state

The master node is in the complete state if it can receive at its secondary port the Hello packets sent out its primary port. In this case, the master node blocks the secondary port to prevent traffic loops.

l              Failed state

When a link in the ring fails, the master node is in the failed state. To avoid traffic interruption in the ring, the master node unblocks the secondary port to forward data traffic.

 

&  Note:

The state of the master node represents the state of the whole RRPP ring. That is, when the master node is in the complete (failed) state, the RRPP ring is also in the complete (failed) state.

 

2.1.6  Transit Node

All the nodes except the master node on a ring are transit nodes. For example, in Figure 1, S2, S3, and S4 are transit nodes on the primary ring, and S5 is a transit node on the subring. A transit node transparently transmits Hello packets of the master node, monitors the state of its directly connected RRPP links, and reports link state changes (if any) to the master node to decide the actions to be taken.

A transit node can be in one of the following states depending on the states of its primary and secondary ports:

l              Link-up state

When both the primary port and secondary port are up, the transit node is in the link-up state.

l              Link-down state

When either the primary port or the secondary port is down, the transit node is in the link-down state.

l              Pre-forwarding state

When either the primary port or the secondary port is blocked, the transit node is in the pre-forwarding state.

2.1.7  Edge Node and Assistant-Edge Node

In an RRPP domain, of the two nodes at which the primary ring and a subring intersect, one is the edge node and the other is the assistant-edge node. You can configure either of them as the edge or the assistant-edge but must ensure that the roles of the two nodes are different. In Figure 1, S3 is the edge node, and S2 is the assistant-edge node.

These two roles are significant only on subrings.

Edge nodes and assistant-edge nodes are special transit nodes. An edge or edge-assistant node can be in one of the following three states depending on the state of its edge port:

l              Link-up state

When the edge port is up, the node is in the link-up state.

l              Link-down state

When the edge port is down, the node is in the link-down state.

l              Pre-forwarding state

When the edge port is blocked, the node is in the pre-forwarding state.

The state transition of an edge or edge-assistant node is the same as that of a transit node but it is triggered by the link state change of the edge port only.

2.1.8  Primary Port and Secondary Port

Of the ports that connect a node to an RRPP ring, one is the primary port and the other is the secondary port. You can configure them as needed.

The primary and secondary ports of master nodes are different in functions. A master node sends HELLO messages out its primary port. If it can receive these HELLO messages on its secondary port, the master node considers the RRPP ring as complete and thus blocks the secondary port to avoid loops. If the master node fails to receive these HELLO messages within the specified period, it considers the ring as having failed and unblocks the secondary port to ensure service continuity.

The primary and secondary ports of a transit node are the same in functions.

In an RRPP domain, the primary ring is a logical node of each subring and it transmits subring RRPPDUs (except the EDGE-HELLO messages) transparently as data traffic. Therefore, no data packet or subring RRPPDU (except the EDGE-HELLO messages) can pass through a blocked port on the primary ring.

2.1.9  Common Port and Edge Port

On an edge or assistant-edge node, the port connecting to the subring is called the edge port while the two ports connecting to the primary ring are called common ports. The link between the common port on the edge node and that on the assistant-edge node is called the common link.

As a primary ring is considered as a logical node on its subrings, the common link is considered as an internal link of the “primary ring” node. Thus, the common link state changes are reported only to the master node of the primary ring.

In Figure 1, on the edge node S3, the port connecting to S6 is an edge port, while the ports connecting to S4 and S2 are common ports. The link directly connecting the edge node S3 to the assistant-edge node S2 is the common link.

2.2  RRPPDUs

2.2.1  RRPPDU Types

RRPPDU type

Description

HELLO

Sent regularly by a master node to check ring completeness. If the sent HELLO messages can finally reach the secondary port of the master node within the predefined period, the ring is considered complete; if not, the ring is considered open, in which case a link may have failed on the ring.

LINK-DOWN

Sent by a transit, edge, or edge-assistant node to report link failure to the master node.

COMMON-FLUSH-FDB

Sent by a master node to notify the transit nodes to update their MAC address tables and ARP/ND tables when it transitions to the failed state.

The nodes on the primary ring must update their MAC address table and ARP/ND tables after receiving COMMON-FLUSH-FDB messages, even if they are from the master node on a subring.

COMPLETE-FLUSH-FDB

Sent by a master node to notify the transit nodes to update their MAC address tables and ARP/ND tables when it transitions to the complete state. The transit nodes thus transition to the link-up state, unblocking the temporarily blocked ports.

For the nodes on the primary ring, if the sending master node is on a subring, they will update the MAC address tables and ARP/ND tables, but will not unblock the blocked ports.

EDGE-HELLO

Sent by the edge node of a subring and received by the assistant-edge node of the same subring to check whether the SRPTs of the subring are in good condition.

The edge node periodically sends EDGE-HELLO messages out the two common ports to the assistant-edge node across the primary ring. If the assistant-edge node receives the messages, the SRPTs are considered as in good condition; if the assistant-edge node does not receive the messages within a specified period of time, the SRPTs are considered as faulty.

MAJOR-FAULT

Sent by an assistant-edge node to report SRPT failure to the edge node. Upon receiving a MAJOR-FAULT message, the edge node blocks its edge port.

 

2.2.2  RRPPDU Format

Figure 2 RRPP RRPPDU format

The following table describes each field in an RRPPDU:

Field

Length (in bits)

Description

Destination MAC Address

48

Destination MAC address, in the range of 0x000FE2078217 to 0x000FE2078416.

Source Mac Address

48

Source MAC address, fixed to 0x000fe203fd75.

EtherType

8

Encapsulation type, fixed to 0x8100 indicating tagged encapsulation.

PRI

4

Class of service (CoS) priority, fixed to 0xe0.

VLAN ID

12

ID of the VLAN to which the packet belongs.

Frame Length

16

Ethernet frame length, fixed to 0x48.

DSAP/SSAP

16

Destination service access point/source service access point, fixed to 0xaaaa.

CONTROL

8

Fixed to 0x03.

OUI

24

Fixed to 0x00e02b.

RRPP Length

16

RRPP protocol data unit length, fixed to 0x40.

RRPP_VER

16

RRPP version, 0x0001 currently.

RRPP Type

8

RRPPDU type:

l      5: HELLO

l      6: COMPLETE-FLUSH-FDB

l      7: COMMON-FLUSH-FDB

l      8: LINK-DOWN

l      10: EDGE-HELLO

l      11: MAJOR-FAULT

Domain ID

16

ID of the RRPP ring to which the packet belongs.

Ring ID

16

ID of the RRPP ring to which the packet belongs.

SYSTEM_MAC_ADDR

48

Bridge MAC address of the node sending the packet.

HELLO_TIMER

16

Hello timer setting (in seconds) of the sending node.

FAIL_TIMER

16

Fail timer setting (in seconds) of the sending node.

LEVEL

8

Level of the RRPP ring to which the packet belongs.

 

2.3  Single Ring Fundamentals

2.3.1  Single-Domain Single Ring

This section describes how RRPP works and how ring topology converges by analyzing the Ethernet ring status change from complete to failed, and then back to complete.

1. Ring status detection and related operations

RRPP uses a polling mechanism to check ring completeness: the master node sends Hello messages to the ring regularly. These Hello messages pass through each transit node on the ring in turn. If they can finally reach the secondary port of the master node, the ring is considered complete. In this case, to avoid broadcast loops on the ring, the master node keeps its secondary port blocked. Figure 3 shows a closed RRPP ring.

Figure 3 A complete RRPP ring

2. Fault detection and related operations

Ring faults can be detected by using one of the following mechanisms:

l              Polling mechanism

l              Link down alarm mechanism

1)         Polling mechanism

RRPP uses a polling mechanism to check ring faults.

With this mechanism, a master node sends Hello messages to the ring regularly. These Hello messages pass through each transit node on the ring in turn. If they fail to reach the secondary port of the master node within a specified period of time, the ring is considered open, in which case at least one link may have failed on the ring. In this case, the master node transitions to the failed state, unblocks the secondary port, and sends COMPLETE-FLUSH-FDB messages out its primary and secondary ports to instruct all the transit nodes to update their MAC address table entries and ARP/ND entries.

2)         Link down alarm mechanism

A node is always monitoring its own port link status, and takes immediate actions upon detecting a failed port.

l              When a master node’s primary port goes down, the master node is able to sense the link fault by itself. It immediately unblocks its secondary port, and sends a COMPLETE-FLUSH-FDB message out its secondary port to instruct all the transit nodes to update their MAC address table entries and ARP/ND entries.

l              When one port on a transit node goes down, the transit node sends a LINK-DOWN message out the other RRPP port that is still up to notify the master node, as shown in Figure 4. Upon receiving the message, the master node unblocks its secondary port and transitions to the failed state. To avoid packet direction errors due to the topology change, the master node updates its own MAC address table and ARP/ND entries and sends a COMMON-FLUSH-FDB message out its primary and secondary ports to instruct all the transit nodes to update their MAC address table entries and ARP/ND entries. See Figure 5 for the process of a master node transitioning from the complete state to the failed state.

Figure 4 A transit node sends a LINK-DOWN message to the master node

Figure 5 The master node transitions to the failed state

The link-down alarm mechanism provides faster fault protection than the polling mechanism. However, if LINK-DOWN messages are lost on the way to the master node, the link faults will be detected later by the master node using the polling mechanism. If the master node fails to receive on its secondary port the Hello messages it sends out within a period of time specified by the Fail timer, it considers the ring topology as faulty, and then takes related actions as described earlier.

3. Fault recovery detection and related operations

When a failed port on a transit node recovers, the master node cannot be notified of the recovery immediately. Hence, the master port’s secondary port is still up. If the transit node transitions to the Link-Up state at once, a temporary loop will be created on the ring. Therefore, when a Link-Down transit node’s primary and secondary ports are both recovered, the transit node blocks them immediately and transitions to the pre-forwarding state, as shown in Figure 6. At this point, the ring is not recovered yet. The master node initiates the ring recovery process.

Figure 6 A transit node blocks its recovered ports and transitions to the pre-forwarding state

When all the links on the ring recover and the master node is able to receive its own Hello packets again, it blocks the secondary port and transitions back to the complete state. Because of the ring topology change, the master node needs to update its MAC address table entries and ARP/ND entries, and sends COMPLETE-FLUSH-FDB messages to instruct all the transit nodes to update their MAC address table entries and ARP/ND entries. When receiving the COMPLETE-FLUSH-FDB message from the master node, the transit nodes in the pre-forwarding state transition to the Link-Up state. Thus the ring is recovered, as shown in Figure 7.

Figure 7 How a ring recovers

In case the COMPLETE-FLUSH-FDB messages fail to reach a transit node, the transit node in the pre-forwarding state unblocks the blocked port automatically, updates its MAC address table entries and ARP/ND entries and transits to the link-up state if it fails to receive any COMPLETE-FLUSH-FDB messages from the master node within the period of time specified by the Fail timer.

2.3.2  Multi-Domain Single Ring

If traffic of multiple VLANs exists on an RRPP ring, you can configure multiple RRPP domains on the RRPP ring, with each domain transmitting traffic for different VLANs (protected VLANs). In this way, data traffic of different VLANs is transmitted along different paths on the ring, thus achieving load sharing.

Figure 8 Multi-domain single ring

As shown in Figure 8, Ring 1 is configured as the primary ring in both Domain 1 and Domain 2. Domain 1 and Domain 2 have different protected VLANs. In Domain 1, Device A is configured as the primary node on Ring 1, while in Domain 2, Device B is configured as the primary node on Ring 1. Under such configurations, traffic of different VLANs is transmitted along different paths.

2.4  Intersecting Ring Fundamentals

2.4.1  Single-Domain Intersecting Rings

In a single-domain intersecting rings topology, the implementation of the primary ring and the fault detection mechanism used by the subrings’ master nodes are the same as those used on a single-ring topology. The difference is that the SRPT state detection mechanism is used on a multi-ring topology to prevent data loops on the subrings when both SRPTs are disconnected. Before the master node on a subring unblocks its secondary port, the edge node blocks its edge port, thus preventing broadcast loops on the subrings. For more information about the SRPT state detection mechanism, refer to SRPT State Detection Mechanism.

Additionally, when the nodes on the primary ring receive COMMON-FLUSH-FDB or COMPLETE-FLUSH-FDB messages from a subring, they must update their MAC address table entries and ARP/ND entries. However, the COMPLETE-FLUSH-FDB messages from a subring cannot make a transit node on the primary ring to unblock its temporarily-blocked port.

Figure 9 Single-domain intersecting rings

2.4.2  Multi-Domain Intersecting Rings

If traffic of multiple VLANs exists in an intersecting RRPP rings topology, you can configure multiple RRPP domains for the intersecting rings, with each domain transmitting traffic for the specified protected VLANs. Each RRPP domain in the multi-domain topology works in the same way as a single domain does. In this way, data traffic of different VLANs is transmitted along different paths on the ring, thus achieving load sharing.

Figure 10 Multi-domain intersecting rings

As shown in Figure 10, Ring 1 and Ring 2 are respectively configured as the master ring and subring in both Domain 1 and Domain 2. They have different protected VLANs. In Domain 1, Device A is configured as the master node of Ring 1, while in Domain 2, Device D is configured as the master node of Ring 1. In both Domain 1 and Domain 2, Device E is configured as the master node of Ring 2. However, for Domain 1 and Domain 2, the primary and secondary ports on Device E are different. In this way, traffic of different VLANs can be transmitted along different paths in the primary ring and subrings, thus achieving load sharing on the intersecting rings.

2.4.3  SRPT State Detection Mechanism

1. Introduction to SRPT state detection mechanism

SRPTs are tunnels for subring packets on the primary ring. The primary ring as a whole serves as a logical node on the subrings, and protocol packets from the subrings are transparently transmitted through the primary ring. The primary ring forwards protocol packets (except EDGE-HELLO packets) from the subrings as data packets.

Each subring has two SRPTs. As shown in Figure 11, the two SRPTs for subrings Ring 2 and Ring 3 are S3-S2 and S3-S4-S1-S2. When the primary ring is healthy, the secondary port of its master node is blocked, in which case only the S3-S2 tunnel is available. When fault occurs on the S3-S4-S1-S2 tunnel, the S3-S2 tunnel is available; when fault occurs on the S3-S2 tunnel, the S3-S4-S1-S2 tunnel is available. In other words, of a subring’s two SRPTs, only one of them is available at any point of time, thus preventing data loops on the primary ring for subring protocol packets. When both the SRPTs of a subring fail, and the subring’s master node fails to receive its own Hello packets within the period of time specified by the Fail timer, the subring’s master node unblocks its secondary port. In this way, the subring can restore communication to the maximum extent without creating data loops.

This works fine in a common RRPP network topology but not in a dual-homed RRPP ring topology. As shown in Figure 11, the two subrings Ring 2 and Ring 3 are interconnected through the edge node and assistant-edge node and form a loop naturally. Therefore, data loops are unavoidable when the secondary ports on the master nodes of the subrings are unblocked after the two SRPTs on Ring 1 went down. The arrows in the figure indicate traffic directions.

Figure 11 Loops in a dual-homed ring topology without SRPT state detection

To address the problem, the SRPT state detection mechanism is introduced, which is carried out by the edge and assistant-edge nodes together. When the edge node detects that both the SRPTs are down, it blocks the edge ports on the edge nodes before the secondary ports on the master nodes of the subrings are both unblocked. Thus, loops are avoided. Figure 12 shows how loops are removed with the SRPT state detection mechanism.

Figure 12 Loop removal in a dual-homed ring topology with SRPT state detection

2. SRPT state detection process

In the SRPT state detection mechanism, the edge node initiates SRPT state detection and determines the actions to take; the assistant-edge node monitors SRPT state and notifies the edge node of SRPT state changes, if any. The following subsections describe how the mechanism works.

1)         Detecting SRPT state

The edge node of a subring periodically sends EDGE-HELLO messages destined for the assistant-edge node out the two ports connecting the subring to the SRPTs. The EDGE-HELLO messages travel through each node on the SRPTs, as shown in Figure 13. If at least one SRPT is normal for transmitting subring protocol packets, the assistant-edge node can receive these EDGE-HELLO messages within the specified period of time. If the two SRPTs are both disconnected and the subring protocol packets cannot travel through the primary ring, the assistant-edge node cannot receive these EDGE-HELLO messages within the specified period of time.

Figure 13 The edge node sends EDGE-HELLO messages

2)         Blocking the edge port of the edge node when the SRPTs are disconnected

Upon detecting that the two SRPTs are both disconnected, the assistant-edge node sends MAJOR-FAULT messages out the edge port to the edge node through the subring. If the subring is normal, the edge node can receive these MAJOR-FAULT messages. Upon receiving the MAJOR-FAULT messages, the edge node blocks its edge port as shown in Figure 14. If the subring fails, the edge port of the edge node will not be blocked.

MAJOR-FAULT messages are sent periodically. If the edge node receives them, its edge port stays blocked; if the edge node fails to receive any MAJOR-FAULT message within the specified period of time, its edge port is unblocked automatically.

Figure 14 The edge node blocks its edge port upon receiving MAJOR-FAULT messages

3)         Transitioning to the failed state when the subring fails

As the master node on the subring cannot receive the HELLO messages it sent out due to disconnection of the two SRPTs, it unblocks its secondary port and transitions to the failed state, as shown in Figure 15.

Figure 15 The subring’s master node transitions to the failed state due to SRPT disconnection

4)         SRPT recovery

When the primary ring recovers, the SRPTs also recover. Therefore, the assistant-edge node stops sending MAJOR-FAULT messages.

In this case, if the subring is normal, its master node can receive its own Hello packets again, and thus blocks its secondary port and transitions to the complete state, as shown in Figure 16.

Figure 16 SRPT recovery

After the subring is recovered, its master node sends COMPLETE-FLUSH-FDB messages out the primary port. Upon receiving the COMPLETE-FLUSH-FDB messages, the edge node unblocks its edge port if the port is blocked, as shown in Figure 17. Thus, communication in the entire network is recovered.

Figure 17 The edge node of the subring unblocks the edge port

If a fault is present on the subring when the SRPTs recover, the subring cannot be recovered. In this case, the master node of the subring does not send COMPLETE-FLUSH-FDB messages and the blocked edge port of the edge node will be unblocked only after the Fail timer expires.

3. Ring group

In SRPT state detection, the edge node and assistant-edge node of subrings respectively sends and receives EDGE-HELLO packets frequently. As shown in 1. Figure 11 in the multi-ring dual-homed topology, if you configure S2 and S3 as the edge node and assistant-edge node of both Ring 2 and Ring 3, S2 needs to send EDGE-HELLO packets for both Ring 2 and Ring 3, while S3 needs to receive EDGE-HELLO packets for both Ring 2 and Ring 3. The more subrings are configured, the more EDGE-HELLO packets will occur in the network, thus increasing the CPU load of the devices.

To reduce Edge-Hello traffic, you can configure a group of subrings on the edge node or assistant-edge node. A ring group configured on the edge node is called an edge node ring group, and a ring group configured on an assistant-edge node is called an assistant-edge node ring group. In an edge node ring group, only an active subring with the smallest domain ID and ring ID sends EDGE-HELLO packets; in an assistant-edge node ring group, a random active subring receives the EDGE-HELLO packets and passes the information to other active subrings. In this way, after subring groups are configured on the edge node and assistant-edge node, only one subring in each group sends/receives EDGE-HELLO packets, thus reducing the device CPU load significantly.

You must configure a device as the edge node of these subrings, and another device as the assistant-edge node of these subrings. Additionally, these subrings must have the same SRPTs.

Application Scenarios

3.1  Single-Domain Single Ring

Figure 18 Network diagram for a single-domain single-ring network

A single-domain single-ring network has only one ring. Therefore, you need to define only one RRPP domain and one RRPP ring.

A single-domain single-ring network features fast response to topology changes and fast topology convergence.

3.2  Multi-Domain Single Ring

Figure 19 Network diagram for a multi-domain single-ring network

A multi-domain single-ring network has only one ring, but multiple VLANs for the purpose of load sharing. Multiple RRPP domains are configured in the network, each having its own protected VLANs. In addition, an RRPP ring has different master nodes in different RRPP domains or has the same master node but different primary/secondary ports in different RRPP domains. Therefore, the protected VLANs of different RRPP domains have different logical topologies.

3.3  Tangent Rings

Figure 20 Network diagram for a tangent-ring network

A tangent-ring network contains two or more rings. Every two rings have only one common node. For each ring, you are required to define an independent RRPP domain.

The tangent-ring topology is suitable for large-scale networks that require networks at the same level to be managed as independent domains.

3.4  Single-Domain Intersecting RRPP Rings

Figure 21 Networking diagram for single-domain intersecting rings

A single-domain intersecting-ring network contains two or more rings. Every two rings have two common nodes. In this case, you can define one RRPP domain. In the domain, configure a ring as the primary ring and the other rings as subrings.

A typical single-domain intersecting-ring topology is dual-homed rings where the master node of a subring is dually uplinked to the primary ring through the edge node and the assistant-edge node for uplink backup.

3.5  Multi-Domain Intersecting RRPP Rings

Figure 22 Networking diagram for multi-domain intersecting rings

A multi-domain intersecting-ring network contains two or more rings. Every two rings have two common nodes. To achieve load sharing when data traffic of multiple VLANs exists in the network, you can configure multiple RRPP domains in the network, each having its own protected VLANs. In addition, an RRPP ring has different master nodes in different RRPP domains or has the same master node but different primary/secondary ports in different RRPP domains. In this way, the protected VLANs of different RRPP domains can have different logical topologies.

3.6  RRPP in Combination with STP

RRPP is mutually exclusive with STP on a port because RRPP may conflict with STP in port state calculation. An RRPP ring can be connected to an STP ring only in the tangent mode, where no common ports exist between rings.

Figure 23 RRPP in combination with STP

 

 

 

 

 

Copyright ©2008 Hangzhou H3C Technologies Co., Ltd. All Rights Reserved

Extracting and copying partial or whole contents of the document without H3C’s written permission is prohibited.

The information is this document is subject to due modification.