WO2008028392A1

WO2008028392A1 - A loop avoidance method after the recovery from the rpr faults

Info

Publication number: WO2008028392A1
Application number: PCT/CN2007/002082
Authority: WO
Inventors: Eloong Zhang; Yanchun Liu
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-09-01
Filing date: 2007-07-06
Publication date: 2008-03-13
Also published as: CN101136830B; CN101136830A

Abstract

A loop avoidance method after the recovery from the RPR faults, comprises: setting the maximum transmission unit value of a fault recovery node as a predetermined value after acquiring the recovery from the fault of a fault node in the RPR, transmitting the notifying message to the cross ring device in the RPR which notifies that the fault node has been recovered; each the cross ring device in the RPR receiving the notifying message transmitted by the fault recovery node device in the RPR, detecting the work state of each the cross ring device in the RPR, and maintaining only one of the cross ring devices in the RPR as the master.

Description

Loop avoidance method after elastic packet data bridge ring failure recovery

Technical field

The present invention relates to the field of network communication technologies, and in particular, to a loop avoidance method after a fault recovery of an RPR (Resilient Packet Ring) bridge. Background technique

RPR technology is a new network architecture and technology designed to meet the requirements of packet metropolitan area networks. It is a ring network composed of packet switching nodes. Adjacent nodes are connected by a pair of optical fibers. The network topology is based on Two rings transmitted in opposite directions. RPR has the following technical features: 1. Effective reuse of transmission bandwidth; 2. Fast loop bridge protection switching function; 3. Automatic discovery of topology.

A ring network composed of RPR technology is called an RPR ring network and can be simply referred to as an RPR ring. A packet switching device on a ring network is called an RPR device. When the RPR device uses the 48-bit MAC address used in the Ethernet as the address identifier to uniquely identify the RPR device and carries Layer 2 Ethernet packets through the Ethernet Over RPR, the RPR ring can also be called the RPR bridge ring. Or bridge mode RPR ring. The device on the RPR bridge ring can also be called an RPR bridge device. The MAC address on the RPR bridge device can also be called the RPR MAC address. As shown in Figure 1, the structure of the two RPR bridge rings intersects the two RPR bridge devices.

In Figure 1, there are two RPR bridge rings, which are RPR bridge ring 1 and RPR bridge ring 2, respectively. There are four RPR bridge devices on each RPR bridge ring, and the RPR bridge ring 1 and the RPR bridge ring 2 intersect at the RPR cross-bridge device 1 and the cross-ring bridge device 2. The cross-ring bridge device is an RPR bridge device that is connected to two RPR bridge rings at the same time and is responsible for forwarding data packets between two RPR bridge rings. To simplify the description, the RPR cross-ring bridge device is simply referred to as a cross-loop bridge device in the following description.

On the RPR bridge ring, the RPR bridge ring carries Layer 2 Ethernet packets, and the packets between the RPR bridges are forwarded through the Address Resolution Protocol (MAC). Therefore, The RPR cross-loop bridge device where the two RPR bridge rings intersect generates a loop, that is, a loop occurs between the RPR cross-bridge device 1 and the RPR cross-bridge device 2 as shown in FIG. 1, and a broadcast storm occurs.

The current method is through the Spanning Tree Protocol (STP), or Rapid Spanning Tree Protocol (RSTP) protocol performs link reduction, generates a minimum spanning tree without loops, and then forwards packets on Layer 2 Ethernet according to the minimum spanning tree to prevent Layer 2 network communication from forming. Loop. When a device or link fails on the Layer 2 network, STP or RSTP re-calculates the minimum spanning tree and obtains a new forwarding tree to ensure that the fault can occur after the fault occurs.

Although the above method can solve the problems that may occur between the cross-ring bridge devices, this method is slow because the STP and RSTP convergence speed is slow. Even if the RSTP can only reach the convergence speed level of the second-level, the network communication time is prolonged. Increase the load of network communication.

A RPR bridge redundancy protection method is also available. The method is to enter a new protocol type. With the interaction of the protocol and the triggering of the single-loop RPR protection switching, the protection switching capability of 100 ms can be achieved.

However, when two faults occur between two RPR cross-bridge devices in a ring and appear on both sides of an RPR cross-loop bridge device, as shown in Figure 2, to ensure two bridge rings ( Any point between the RPR bridge ring 1 and the RPR bridge ring 2) is reachable. Both RPR cross-ring bridge devices are responsible for forwarding the cross-ring service (both in the active state). In this case, when one of the node failures (such as fault point 1) is restored, there is no fault point in the adjacent section of RPR bridge device 1 and RPR bridge device 2, and the working modes of RPR bridge device 1 and RPR bridge device 2 will The change is in the normal state, and the data point can be forwarded after the recovery point. However, since the RPR cross-ring bridge device cannot immediately perceive this change and cannot change its working state immediately, the two RPR cross-ring bridge devices are still in the master state and are responsible for the data service of the cross-ring bridge. Forwarding, this will cause a broadcast loop problem, as shown in Figure 3.

In the above-mentioned RPR bridge redundancy protection method, when only one fault occurs, after the fault is recovered, the original fault point just returned to normal on the RPR ring is delayed for a period of time before the packet is forwarded or broadcast data is reported. Forwarding of text to avoid broadcast loops. For the case of two failure points, there is no clear solution in the current scheme. Summary of the invention

In view of the above problems in the prior art, an object of embodiments of the present invention is to provide an RPR bridge. The loop avoidance method after the fault recovery, the method solves the broadcast loop problem that may occur when one fault point recovers after two fault points occur on one RPR bridge loop in the application scenario of the RPR intersecting loop.

In order to achieve the above object, an embodiment of the present invention provides a loop avoiding method after RPR bridge fault recovery, and the method includes the following steps:

A. After learning the fault recovery of the fault point in the RPR bridge loop, setting the maximum transmission unit value of the fault recovery node to a predetermined value, and sending the cross-bridge device in the RPR bridge ring to notify the fault point The notification message that the fault has been recovered;

B. Each RPR cross-ring bridge device in the RPR bridge ring receives the notification message sent by the fault recovery node, detects the working status of the respective RPR cross-ring bridge device, and only maintains one of the primary RPR cross-bridge devices. Main state.

Preferably, the step A further includes:

Before the maximum transmission unit value of the failover node is set, the normal maximum transmission unit value of the failure recovery node is recorded.

Preferably, after the step A, the method further includes:

The network topology convergence is initiated, and after the topology is converged, the maximum transmission unit value of the fault recovery node is restored to the recorded normal maximum transmission unit value.

Preferably, the step A further includes:

After the maximum transmission unit value is set to the predetermined value, the operational state of the fault recovery node is set to a normal state.

Preferably, the predetermined value of the maximum transmission unit value is a value that can ensure that the protocol message passes, and the data message cannot pass, and the value is between 30 and 81.

Preferably, the step B further includes:

Compare the priority of each RPR cross-bridge device to keep the highest-priority RPR cross-bridge device in the active state.

Preferably, in step A, it is known that the fault of the fault point in the RPR bridge loop has returned to normal: when the fault point is the RPR bridge device in the RPR bridge ring, the fault point itself is known. Its The fault has returned to normal;

When the fault point is not the RPR bridge device in the RPR bridge ring, it is known by the fault recovery node adjacent to the fault point that the fault of the fault point has returned to normal.

Preferably, the fault recovery node in the RPR bridge ring is an RPR bridge device or an RPR span bridge device. Preferably, the notification message is a type of message that is extended on the basis of the existing message, or is a newly defined message.

Preferably, in step B, when a cross-ring bridge device detects that its working state is a standby state, the received notification message is not processed.

Preferably, in the step B, when a cross-ring bridge device detects that its working state is the active state, but does not have other cross-ring bridge devices connected to it in the active state; or when a cross-bridge device If the working status of the working state is detected as the active state, but the priority is higher than the priority of other cross-ring bridge devices connected to the active state, the received notification message will not be processed. .

Preferably, in the step B, when a cross-ring bridge device detects that its working state is in the active state, and the other cross-ring bridge devices connected to the active state have a higher priority cross-ring bridge When the device is in use, the low-priority cross-ring bridge device exits the active state.

The embodiments of the present invention have the following beneficial effects:

In the embodiment of the present invention, the fault recovery node sends a notification message to the cross-ring bridge device. After the cross-ring bridge device receives the notification packet, the cross-loop bridge device works according to its working status/priority and other cross-ring bridge devices. Status/Priority, for subsequent actions (such as maintaining the active state or exiting the active state). In this way, after the fault at the fault point is restored, only one cross-ring bridge device is in the active state, ensuring correct forwarding of the cross-ring service, and solving the loop problem occurring in the information transmission after the fault point is recovered, and there is no service in the ring. Impact, while having no effect on the convergence of the single-ring protocol. DRAWINGS

1 is a schematic diagram of a topology structure of an RPR bridge ring network in the prior art;

2 is a schematic diagram of communication in the case where two faults occur simultaneously on one RPR bridge ring in the RPR bridge ring network in the prior art; 3 is a schematic diagram of a broadcast loop generated when one fault occurs simultaneously on one RPR bridge ring in the RPR bridge ring network in the prior art;

4 is a flowchart of a method for avoiding a broadcast loop by a fault recovery node when a non-cross-bridge device fails to recover in the RPR bridge according to an embodiment of the present invention;

FIG. 5 is a flowchart of a method for avoiding a broadcast loop of a cross-loop bridge device when a non-cross-bridge device fails to recover in the RPR bridge according to an embodiment of the present invention. detailed description

Specific embodiments of the present invention will be described below with reference to the accompanying drawings.

The embodiment of the invention provides a loop avoidance method after the RPR bridge is faulty. The method solves the problem that in the application scenario of the RPR intersecting ring, when two fault points occur simultaneously on one RPR bridge ring, at one fault point A broadcast loop problem that may occur when recovering. The loop avoidance method after the fault recovery of the RPR bridge is to control the passage of data packets on the RPR ring through the cooperation of the fault recovery node and the cross-ring bridge device to avoid loop phenomenon on the RPR ring.

First, please refer to FIG. 2 again. In the example, an RPR bridge ring network is provided, in which there are two intersecting RPR bridge rings, and the two RPR bridge rings include RPR bridge device 1, RPR bridge device 2, and RPR bridge device 3. RPR bridge device 4 and RPR cross-bridge device 1 and RPR cross-bridge device 2. In the case where both the fault point 1 and the fault point 2 exist, the working modes of the RPR bridge device 1 and the RPR bridge device 2 are in the protection mode, that is, the wrap state, and no packet will pass at the fault point 1, and there will be no The emergence of a broadcast loop. To ensure that the two RPR bridges can access each other at any point, the working status of the RPR cross-bridge device 1 and the RPR2 cross-ring bridge device are both in the master state and the cross-ring in the active state. The bridge device can be responsible for forwarding the cross-ring service, that is, the data service can be forwarded in different RPR bridge rings, so that any node in the two RPR bridge rings can access each other.

When the fault point 1 is restored, there is no fault point in the adjacent section of the RPR bridge device 1 and the RPR bridge device 2. The working modes of the RPR bridge device 1 and the RPR bridge device 2 will change to the normal state. After the working mode of RPR bridge device 1 and RPR bridge device 2 becomes normal, the data packet can pass the fault point. Since the RPR cross-loop bridge device cannot immediately perceive this change and does not move the state Move, as shown in Figure 3, a broadcast loop problem may occur. In the following, in conjunction with FIG. 4 and FIG. 5, in the embodiment of the present invention, when the fault point 1 or the fault point 2 is restored, how to cooperate with the fault recovery node and the cross-ring bridge device to avoid the FIG. 3 The emergence of the phenomenon of the middle ring.

Please refer to FIG. 4 , which is a main flowchart of processing a fault recovery node according to an embodiment of the present invention. The fault recovery node referred to herein refers to a device adjacent to the fault point, and for the fault point 1 , the fault recovery node Refers to RPR bridge device 1 or RPR bridge device 2 adjacent to fault point 1. The recovery point 1 in Figure 3 is taken as an example. The process flow includes the following steps:

Step 40: After learning that the fault of the fault point 1 in the RPR bridge ring has returned to normal, triggering a topology convergence process; in the RPR bridge ring, the fault point may be an RPR bridge device or a chain connecting the RPR bridge devices. road. Here, since the fault point 1 is a link, after the fault is recovered, the state of the adjacent RPR bridge device disappears, and the fault recovery node (RPR bridge device 1 or RPR bridge device 2) can know that the fault of the fault point 1 has been Back to normal. In other cases, for example, the point of failure is an RPR bridge device in the RPR bridge ring, in which case the point of failure itself can be informed whether its fault has returned to normal.

Step 41: After the topology changes, determine the fault recovery node (RPR bridge device 1 or RPR bridge device 2) or the fault point (when the fault point is a device in the RPR bridge ring) before completing topology convergence. Whether the working status has changed;

Step 42: The fault recovery node (the RPR bridge device 1 or the RPR bridge device 2) detects whether its own working state changes from a protected state (wrap state) to a normal state. If the detection result is yes, the fault is recovered. When the node has changed to the normal state, go to step 43. If the detection result is no, that is, the fault recovery node is still in the wrap state, wait for a predetermined time (such as 1~3 seconds). Go to step 41 to continue the test;

In this step, if the fault point is an RPR bridge device, it is detected whether the working state of the fault point changes from the protection state to the normal state. Similarly, when the detection result is yes, go to step 43; when the detection result is no Wait for a predetermined time, go to step 41 to continue the test;

Step 43: The fault recovery node sends a notification message on the two RPR bridge rings, and notifies the RPR cross-bridge device 1 and the RPR cross-bridge device 2 that the fault at the fault point 1 has returned to normal; The notification message sent by the fault recovery node may be a packet that is extended based on an existing packet, or may be a packet that uses a new packet type;

Step 44: Record the current normal value of the Maximum Transmission Unit (MTU) of the fault recovery node; and set the MTU value of the fault recovery node to a predetermined value. Preferably, the predetermined value is in the range of 30-81 words. The value between the sections;

The purpose of setting the MTU predetermined value is to ensure that the protocol texts such as TP and TC can pass the fault point 1, and the data packet cannot pass. Because the length of the TP packet is 26 bytes, the length of the TC packet is 29 bytes, the value of the MTU is required to be greater than or equal to 30 bytes, and the length of the RPR packet containing 4 wide data is at least 18 + 64 bytes. (The minimum Ethernet length is 64 bytes) = 82 bytes, so the MTU value can be set from 30 to 81 bytes. For example, it can be set to 64 bytes. When the information is transmitted in the RPR bridge ring, the data packet cannot pass the fault point after the MTU is modified to a predetermined value, which can effectively avoid the loop.

Step 46: After the topology convergence, restore the MTU value of the fault recovery node to the normal value of the MTU recorded in step 44; further, the working state of the fault recovery node may be set to a normal state;

Step 47: The program ends.

Similarly, for fault point 2, the fault recovery node is RPR cross-loop bridge device 1 or RPR cross-loop bridge device 2, when the fault point 2 is restored, the fault recovery node can easily perceive that the fault point 2 has returned to normal. According to the change of its own working state, to avoid the occurrence of a loop, the process of changing its own state will be described with reference to FIG.

When a cross-ring bridge device receives the notification message indicating that the fault point 1 has been recovered in step 43 of FIG. 4 described above, or when it detects that the fault of the adjacent fault point 2 has been recovered, then the cross-ring The bridge device should perform the corresponding data processing process according to its own working state and priority. The main purpose is to keep only one cross-ring bridge device in all cross-ring bridge devices in the active state and to forward data packets across the ring. Other cross-ring bridge devices exit the active state and become standby. The data packets are forwarded across the ring to avoid the loop in Figure 3. The priority described herein refers to an attribute value set for each cross-bridge device according to a certain rule in advance. The priority setting of the cross-bridge device can be Configure it yourself as needed, for example, the device ID number, IP address, MAC address, custom identifier, or custom serial number of the cross-ring bridge device.

The processing of the cross-ring bridge device will be described below with reference to flowchart 5:

Step 51: The cross-ring bridge device (for example, the cross-ring bridge device 1 or the cross-ring bridge device 2) receives the notification message sent from the fault recovery node, or detects that the adjacent fault point has been restored;

Step 52: The cross-ring bridge device determines whether its own working state is in the active state at this time. If it is in the standby state, the received notification message is not processed, and the process proceeds to step 56; if it is the primary use State, go to step 53;

Step 53: Determine whether the cross-ring bridge device has other cross-ring bridge devices connected to the RPR bridge ring in the active state. If not, the cross-ring bridge device remains in the active state, and receives the notification. "^" is not processed, and proceeds to step 56; if there are other cross-bridge devices in its active state connected to it, then go to step 54;

Step 54: Determine whether the priority of the cross-ring bridge device is lower than the priority of other cross-ring bridge devices connected to the primary state. If the judgment result is no, the cross-ring bridge device remains in the active state. And the received notification message is not processed, and proceeds to step 56, if the determination result is yes, then proceeds to step 55;

Step 55: The cross-ring bridge device exits the active state and is no longer responsible for forwarding the cross-ring service. Step 56: The process ends.

In summary, the embodiment of the present invention sends a notification message to the cross-ring bridge device through the fault recovery node. After the cross-ring bridge device receives the notification packet, the cross-ring bridge device 1 and the cross-ring bridge device 2 both according to their own Work status/priority and other working status/priority of the cross-bridge device to perform subsequent actions (such as maintaining the active state or exiting the active state). In this way, after the fault at the fault point is restored, only one cross-ring bridge device is still in the active state, ensuring correct forwarding of the cross-ring service, and solving the loop problem occurring in the information transmission after the fault point is recovered, and the service in the ring is also There is no impact, and there is no impact on the convergence of the single-ring protocol.

The above is only a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto, and any person skilled in the art can easily think of within the technical scope disclosed by the present invention. Changes or substitutions are intended to be included within the scope of the invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

Rights request

A loop avoidance method after an elastic packet data bridge ring fault recovery, characterized in that the method comprises the following steps:

After learning that the fault of the fault point in the elastic packet data bridge loop is restored to normal, the maximum transmission unit value of the fault recovery node is set to a predetermined value, and is sent to the cross-loop bridge device in the elastic packet data bridge ring for Notifying the fault message that the fault has been recovered;

Each elastic packet data ring in the elastic packet data bridge ring receives the notification message sent by the fault recovery node across the ring bridge device, and detects the working state of itself and other elastic packet data ring bridge devices, so that only one of them The primary resilient packet data ring maintains the primary state across the ring bridge device.

2. The loop avoidance method after the resilient packet data bridge ring fault recovery according to claim 1, further comprising:

Recording a normal maximum transmission unit value of the fault recovery node before setting a maximum transmission unit value of the fault recovery node to a predetermined value;

After transmitting the notification message for notifying that the failure of the fault point has been restored, the network topology convergence is triggered, and after the topology convergence, the maximum transmission unit value of the fault recovery node is restored to the recorded normal maximum. Transfer unit value.

The loop avoidance method after the resilient packet data bridge ring fault recovery according to claim 1 or 2, wherein: the predetermined value of the maximum transmission unit value is a value between 30 and 81 bytes.

The loop avoidance method after the fault recovery of the elastic packet data bridge ring according to claim 3, wherein the fault recovery of the fault point in the learned elastic packet data bridge ring is normal: When the point is the elastic packet data ring bridge device in the elastic packet data bridge ring, the fault point itself knows that the fault has returned to normal;

When the fault point is not the elastic packet data ring bridge device in the elastic packet data bridge ring, it is learned by the fault recovery node adjacent to the fault point that the fault of the fault point has returned to normal.

The loop avoidance method after the resilient packet data bridge ring fault recovery according to claim 4, wherein the fault recovery node in the elastic packet data bridge ring is an elastic packet data ring bridge device or elastic packet data. Ring spanning bridge equipment.

The loop avoidance method after the fault recovery of the elastic packet data bridge ring according to claim 1 or 2, further comprising:

The priority of each elastic packet data ring across the ring bridge device is compared, so that the highest priority resilient packet data ring maintains the primary state across the ring bridge device.

The loop avoidance method after the resilient packet data bridge ring fault recovery according to claim 6, further comprising:

When a cross-ring bridge device detects that its working state is the active state, but does not have other cross-ring bridge devices connected to it in the active state; or when a cross-loop bridge device detects its own working state as the active state, However, if the priority is higher than the priority of other cross-ring bridge devices connected to it in the active state, the notification message received will not be processed.

When a cross-ring bridge device detects that its own working state is the active state, and there is a higher priority cross-ring bridge device among other cross-ring bridge devices connected to the active state, the low-priority cross-span The ring bridge device exits the active state.

The loop avoidance method after the fault recovery of the elastic packet data bridge ring according to claim 1 or 2, wherein the notification packet is a packet that is extended and implemented on the basis of the existing packet. Or a newly defined message.

When a cross-loop bridge device detects that its working state is the standby state, the notification message received by the device does not process the message.

A loop avoidance system after a resilient packet data bridge ring fault recovery, including a cross-ring bridge device, further comprising:

a maximum transmission unit value setting module, configured to set a maximum transmission unit value of the fault recovery node to a predetermined value after the fault of the fault point in the elastic packet data bridge loop is recovered;

a sending module, after the fault of the fault point in the elastic packet data bridge is recovered, Sending, to the cross-ring bridge device in the elastic packet data bridge ring, a notification message for notifying that the fault point has been recovered;

The primary state setting module is connected to the cross-loop bridge device, and is configured to detect, after the elastic packet data ring bridge device in the elastic packet data bridge ring receives the notification message sent by the sending module, Other resilient packet data loops work across the ring bridge device, such that only one of the primary resilient packet data loops remains in the primary state across the ring bridge device.

12. The loop avoidance system after resilient packet bridgeback fault recovery according to claim 11, further comprising a recording module, configured to: before setting a maximum transmission unit value of the fault recovery node to a predetermined value Recording a normal maximum transmission unit value of the fault recovery node;

The maximum transmission unit value setting module is further configured to trigger network topology convergence after transmitting a notification message for notifying that the fault has been recovered, and after the topology convergence, the fault recovery node is maximized. The transmission unit value is restored to the recorded normal maximum transmission unit value.

The loop avoidance system after the resilient packet data bridge ring fault recovery according to claim 11 or 12, wherein: the predetermined value of the maximum transmission unit value is a value between 30 and 81 bytes.

The loop avoidance system after the fault recovery of the elastic packet data bridge ring according to claim 11 or 12, wherein the main state setting module comprises a priority judging unit and a setting unit, wherein:

a priority determining unit, configured to compare priority of each elastic packet data ring across the ring bridge device; and a setting unit, configured to keep the highest priority resilient packet data ring that is determined according to the priority determining unit as a cross-bridge device Main state.

The loop avoidance system after the fault recovery of the elastic packet data bridge ring according to claim 14, wherein the cross-loop bridge device is further configured to detect the active state of the working state, but not When connecting other cross-loop bridge devices in the active state; or when detecting that their own working state is active, but their priority is higher than the priority of other cross-ring bridge devices connected to them in the active state , the received notification message is not processed.

The loop avoidance system after the resilient packet data bridge ring fault recovery according to claim 15, further comprising: The cross-ring bridge device is further configured to exit the primary device when a cross-ring bridge device with a higher priority exists in the other cross-ring bridge devices connected to the active state in which the active state is detected as the active state. status.