A fault transparent transmission method, device and electronic device

Abstract

The present application discloses a fault pass-through method, apparatus and electronic device. By detecting the alarm status of each port of an upstream device and saving the alarm information into the port, where the alarm information is used to indicate the alarm status; mapping the alarm information to the ports of a downstream device and saving the alarm information into the ports of the downstream device; reading the alarm information saved in the ports of the downstream device and performing fault handling according to the alarm information saved in the ports of the downstream device, the whole process does not require the participation of a main controller, reducing the time from detecting an alarm to transmitting the alarm information to the downstream device.

Description

Technical Field

[0001] The present invention relates to network communication technologies, and more particularly, to a fault pass-through method, apparatus, and electronic device. Background Art

[0002] With the advent of the 5G era, data traffic has grown exponentially, and the services carried by the network have gradually become more diversified, which poses higher requirements for the stability and reliability of telecommunication transmission equipment. The ability of the equipment to perceive and respond to link failures directly determines whether the network link can switch to the backup link and quickly resume services in a short time when a failure occurs. Fault pass-through is an important means for the equipment to perceive remote failures and is widely used in telecommunication equipment, which is favored by operators. In cooperation with the scenario of service protection, when a network link fails, fast fault pass-through can effectively reduce the switching time of the entire link and greatly improve the stability and reliability of the network. At the same time, in cooperation with the fault delay insertion function, it can effectively avoid unnecessary switching caused by temporary link jitter, thus greatly reducing the maintenance cost of the entire network.

[0003] Traditional fault pass-through methods are based on the OAM protocol, and the decision-making for fault alarm processing is carried out by the main control. That is, when the equipment detects an alarm, it will report it to the main control, and the main control will issue commands for pass-through or alarm insertion. Due to the participation of the main control in the pass-through process, the time taken for the upstream equipment to detect the alarm and transmit this alarm information to the downstream equipment is relatively long, usually reaching the second level, which cannot meet the requirements of operators at the millisecond level. Summary of the Invention

[0004] At least one embodiment of the present invention provides a fault pass-through method, apparatus, device, and storage medium, which map the alarm information detected by the upstream equipment to the downstream equipment through a chip without the participation of the main control, reducing the time from detecting the alarm to transmitting this alarm information to the downstream equipment.

[0005] To achieve the object of the present invention, at least one embodiment of the present invention provides a fault pass-through method, including:

[0006] Detect the alarm status of each port of the upstream equipment and save the alarm information to the port, where the alarm information is used to indicate the alarm status;

[0007] Specifically, it includes: detecting the alarm status of each port of the upstream equipment every first preset period, and writing the detected alarm information into the chip register or entry corresponding to the port.

[0008] Map the alarm information to the port of the downstream equipment and save the alarm information to the port of the downstream equipment;

[0009] Specifically, it includes: mapping the alarm information to the port of the downstream device by sending an OAM alarm message, and writing the alarm information into the chip register or entry corresponding to the port of the downstream device.

[0010] Read the alarm information saved in the port of the downstream device, and perform fault handling according to the alarm information saved in the port of the downstream device.

[0011] Specifically, it includes: polling the port of the downstream device once every second preset period;

[0012] Read the alarm message in the corresponding chip register or entry through the port;

[0013] Perform fault handling according to the alarm information.

[0014] Preferably, the method further includes: clearing the alarm information of the port of the downstream device when no alarm message sent by the port of the upstream device is received within the third preset period.

[0015] Preferably, the chip is any one of the following: a logic chip, an NP network processor chip, a switching chip, or a CPU central processing unit chip.

[0016] Preferably, the first preset period, the second preset period, or the third preset period is set by a timer.

[0017] Compared with the related art, the fault transparent transmission method provided by the present application detects the alarm status of each port of the upstream device, saves the alarm information in the port; maps the alarm information to the port of the downstream device, and saves the alarm information in the port of the downstream device; reads the alarm information saved in the port of the downstream device, and performs fault handling according to the alarm information saved in the port of the downstream device, without the participation of the main control throughout the process, reducing the time from detecting the alarm to transmitting the alarm information to the downstream device.

[0018] At least one embodiment of the present invention provides a fault transparent transmission device, including:

[0019] A detection module, configured to detect the alarm status of each port of the upstream device, and save the alarm information in the port, where the alarm information is used to indicate the alarm status;

[0020] A mapping module, configured to map the alarm information to the port of the downstream device, and save the alarm information in the port of the downstream device;

[0021] A reading module, configured to read the alarm information saved in the port of the downstream device, and perform fault handling according to the alarm information saved in the port of the downstream device.

[0022] Preferably, the device further includes: a clearing module, configured to clear the alarm information of the port of the downstream device when no alarm message sent from the port of the upstream device is received within a third preset period.

[0023] At least one embodiment of the present invention provides an electronic device, including: a processor and a memory; a fault pass-through program is stored in the memory, and the processor is configured to run the fault pass-through program to execute the steps in any one of the above method embodiments.

[0024] At least one embodiment of the present invention provides a computer-readable storage medium, on which a program for fault pass-through is stored, wherein the fault pass-through program is configured to execute the steps in any one of the above method embodiments when running.

[0025] Other features and advantages of the present invention will be described in the following specification, and in part will be obvious from the specification, or will be understood by implementing the present invention. The objectives and other advantages of the present invention can be realized and obtained by the structures specifically pointed out in the specification, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The drawings are used to provide a further understanding of the technical solutions of the present invention, and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the technical solutions of the present invention, and do not constitute a limitation to the technical solutions of the present invention.

[0027] Figure 1 Flowchart of a fault pass-through method according to an embodiment of the present invention;

[0028] Figure 2 Block diagram of a fault pass-through device according to an embodiment of the present invention;

[0029] Figure 3 Application scenario of a fault pass-through method according to an embodiment of the present invention;

[0030] Figure 4 Flowchart of fault pass-through from the customer side UNI to the line side NNI according to an embodiment of the present invention;

[0031] Figure 5 It is the flowchart of port alarm detection according to an embodiment of the present invention;

[0032] Figure 6 It is the flowchart of alarm information reading according to an embodiment of the present invention;

[0033] Figure 7 It is the flowchart of fault pass-through from the line side NNI to the customer side UNI in the present invention;

[0034] Figure 8 This is the flowchart of fault transparent transmission from the customer - side UNI RF alarm to the line - side NNI in the present invention. Detailed implementation manners

[0035] To make the objectives, technical solutions and advantages of the present invention clearer and more understandable, the embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be noted that, without conflict, the embodiments and features in the embodiments of the present application can be combined arbitrarily with each other.

[0036] The steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer - executable instructions. And, although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order from that here.

[0037] In an embodiment, as Figure 1 shown, Figure 1 it is a flowchart of a fault transparent transmission method, which specifically includes:

[0038] Step 101, detect the alarm status of each port of the upstream device, and save the alarm information to the corresponding port;

[0039] Specifically, detect the alarm status of each port of the upstream device every first preset period, and write the detected alarm information into the chip register or entry corresponding to this port. Among them, the above - mentioned chip is any one of a logic chip, an NP network processor chip, a switching chip or a CPU central processing unit chip.

[0040] Preferably, enable a timer to poll the alarm status of all ports of the upstream device every first preset period, and write the detected alarm information into the chip register or entry corresponding to the port. Since the port has a latch function for the alarm status, it can be ensured that as long as an alarm occurs, the alarm information can be detected. The first preset period can be configured by the user himself, and is generally configured in milliseconds for rapid alarm detection.

[0041] Step 102, map the alarm information to the port of the downstream device, and save the alarm information to the port of the downstream device;

[0042] Specifically, map the alarm information to the port of the downstream device by sending an OAM alarm message, and write the alarm information into the chip register or entry corresponding to the port of the downstream device.

[0043] Preferably, after the chip register or entry of the port of the upstream device is written with the alarm information, its state changes, and the alarm information is mapped to the port of the downstream device by sending an OAM alarm message. After receiving the alarm mapping, the port of the downstream device also writes the alarm information into the chip register or entry corresponding to the port. Among them, the above chip is any one of a logic chip, an NP network processor chip, a switching chip, or a CPU central processing unit chip.

[0044] Step 103: Read the alarm information saved in the port of the downstream device, and perform fault handling according to the alarm information saved in the port of the downstream device.

[0045] Specifically, the port of the downstream device is polled every second preset period; the alarm message in the corresponding chip register or entry is read through the port; and fault handling is performed according to the alarm information.

[0046] Preferably, a timer task is enabled on the downstream device to poll the port of the downstream device every second preset period, read the corresponding chip register or entry through the port, check whether an alarm occurs or disappears, and perform corresponding fault handling actions according to the checked result, such as closing the port, alarm downlink, etc. Among them, the second preset period can be configured by the user himself, and is generally configured in milliseconds for fast alarm detection.

[0047] Among them, the method further includes: when no alarm message sent by the port of the upstream device is received within the third preset period, the alarm information of the port of the downstream device is cleared.

[0048] Specifically, when the fault alarm of the upstream device disappears, it is also necessary to inform the downstream device. The process of the disappearance of the fault alarm is different from the generation of the alarm. When the downstream device does not receive the alarm message sent by the upstream device port within the third preset period, it will consider that the current alarm has disappeared and will erase the alarm information in the chip register or entry corresponding to the downstream device port. Among them, the third preset period can be configured by the user himself.

[0049] In another embodiment, as Figure 2 shown, Figure 2 is a block diagram of a fault transparent transmission device provided by an embodiment of the present invention, specifically including:

[0050] A detection module 201, configured to detect the alarm status of each port of the upstream device and save the alarm information to the port;

[0051] A mapping module 202, configured to map the alarm information to the port of the downstream device and save the alarm information to the port of the downstream device;

[0052] The reading module 203 is configured to read the alarm information saved in the port of the downstream device and perform fault handling according to the alarm information saved in the port of the downstream device.

[0053] Preferably, the fault transparent transmission device further includes a clearing module 204, configured to clear the alarm information of the port of the downstream device when no alarm message sent by the port of the upstream device is received within a third preset period.

[0054] According to another embodiment of the present invention, an electronic device is further provided. The device includes: a processor and a memory. A fault transparent transmission program is stored in the memory, and the processor is configured to run the fault transparent transmission program to execute the steps in any one of the above method embodiments.

[0055] According to another embodiment of the present invention, a computer-readable storage medium is further provided, on which a fault transparent transmission program is stored. The fault transparent transmission program is configured to execute the steps in any one of the above method embodiments when running.

[0056] The present application will be further described below through specific application examples.

[0057] Application Example 1

[0058] This application example describes the process in which a fault occurs at the customer side UNI ① position of the upstream device network element 1 of the upstream device. After the customer side UNI port detects the fault alarm, the fault alarm is quickly transparently transmitted to the customer side UNI ③ position of the downstream device network element 2, as specifically Figure 3 shown.

[0059] As Figure 4 shown in the flowchart, this embodiment will be described.

[0060] Step 401: Configure a Virtual Private Wire Service (VPWS) and Operation Administration and Maintenance (OAM) on the upstream device network element 1 and the downstream device network element 2, and configure the OAM Mapping function to be enabled on their respective customer side UNI ports, and ensure that the corresponding service flows and OAM are normal;

[0061] Step 402: After the upstream device network element 1 completes initialization, start a timer to poll the alarm status of the port. The timer polling period is configurable. In this embodiment, a polling period of 10 milliseconds is used. Each time, the currently polled alarm status is saved, and the alarm status of the upstream device port is erased. The entire port alarm polling adopts the "read first and then clear" method;

[0062] Step 402 is specifically as follows,Figure 5 The following is the flowchart of port alarm detection in an embodiment of the present invention;

[0063] Step 4021: Enable a timer task to poll the alarm register of the port once every period (this period is configurable, and 10 milliseconds is used in this embodiment), read and save the polled alarm status information, and then clear the alarm register of the corresponding port;

[0064] Step 4022: Determine whether the alarm status of the current port is the same as the status polled last time. If not, proceed to step 4023; if the same, proceed to step 4024;

[0065] Step 4023: Write the alarm status of the current port into the corresponding chip register or table entry, and save the alarm status information of the current port. The above chip is any one of a logic chip, an NP network processor chip, a switching chip, or a CPU central processing unit chip;

[0066] Step 4024: Determine whether the currently polled port is the last port of the device. If so, end this poll; if not, continue to execute step 4021.

[0067] Step 403: The upstream device network element 1 reads the corresponding chip register or table entry of the customer-side UNI port once every period (this period is configurable, and 3.3 milliseconds is used in this embodiment). If there is no alarm information in the chip register or table entry, continue to poll and repeat step 403; if there is alarm information in the chip register or table entry, continuously (the alarm persists, every 3.3 milliseconds) send an OAM alarm message from the line-side NNI port of the device network element 1 to the line-side NNI port of the peer device network element 2 until the alarm in the chip register or table entry corresponding to the customer-side UNI port of the device network element 1 disappears, and then repeat step 403;

[0068] Step 404: The downstream device network element 2 checks once every period (this period is configurable, and 3.3 milliseconds is used in this embodiment) whether it receives an OAM alarm message sent by the fault alarm sending module of the upstream device network element 1 on the corresponding line-side NNI port. If not received, continue to poll. When no OAM alarm message is received on the corresponding port for 3 consecutive periods, it is considered that the peer alarm has disappeared, and the alarm information in the chip register or table entry of the corresponding port of the device network element 2 is cleared, and step 404 is continued; if an OAM alarm message is received, the content of the message is parsed, and the parsed alarm status is written into the chip register or table entry of the corresponding port, and step 404 is repeated;

[0069] Step 405: The downstream device network element 2 starts a timer task, such as Figure 6As shown Figure 6 is the flowchart for reading alarm information in an embodiment of the present invention;

[0070] Poll all ports every other period (this period is configurable, and 10 milliseconds is used in this embodiment). Determine whether the port is a customer - side UNI port. If not, continue to poll the next port and repeat step 405. If it is, read the corresponding chip register or table entry according to the currently polled port number and slot number, and check if there is an alarm. If there is an alarm, perform corresponding actions according to the alarm type (such as LF / RF down - insertion, closing the port, etc.), and repeat step 405. If there is no alarm, check whether corresponding alarm actions have been performed on the current customer - side UNI port;

[0071] Step 406: Read the chip register or table entry corresponding to the line - side NNI port every other period (this period is configurable, and 3.3 milliseconds is used in this embodiment). If no alarm is read for 3 consecutive periods, it is considered that the customer - side UNI alarm of the upstream device network element 1 has disappeared or has not occurred, and repeat step 405.

[0072] Application Example 2

[0073] This application example describes the process in which the downstream device network element 2 has a fault at the line - side NNI ② position. After the line - side NNI port detects the fault alarm, it quickly transmits the fault alarm to the customer - side UNI ③ position of the downstream device network element 2, as Figure 3 shown.

[0074] As Figure 7 shown in the flowchart, this embodiment is described. Figure 7 is the flowchart for fault transmission from the line - side NNI to the customer - side UNI in the present invention;

[0075] Step 701: Configure VPWS services and OAM on the upstream device network element 1 and the downstream device network element 2, enable the OAM Mapping function on their respective customer - side UNI ports, and ensure that the corresponding service flows and OAM are normal;

[0076] Step 702: After the downstream device network element 2 completes initialization, enable a timer to poll the alarm status of the port. The timer polling period is configurable, and a 10 - millisecond polling period is used in this embodiment. Each time, save the currently polled alarm status and erase the alarm status of the port. The entire port alarm polling adopts the method of "reading first and then clearing";

[0077] The specific implementation steps are the same as step 402 in Application Example 1, and will not be elaborated in this Application Example 1.

[0078] Step 703: The downstream device network element 2 starts a timer task, polls all ports every other period (this period is configurable, and in this implementation example, 10 milliseconds is used), and determines whether the port is a customer-side UNI port. If not, continue to poll the next port and repeat step 703; if so, read the corresponding chip register or entry according to the currently polled port number and slot number, check whether there is an alarm. If there is an alarm, perform corresponding actions according to the alarm type (LF / RF down-insertion, port closing, etc.), and repeat step 703; if there is no alarm, check whether corresponding alarm actions have been performed on the current customer-side UNI port;

[0079] Step 704: Read the chip register or entry corresponding to the line-side NNI port every other period (this period is configurable, and in this application example, 3.3 milliseconds is used). If no alarm is read for three consecutive periods, it is considered that the customer-side UNI alarm of the upstream device network element 1 has disappeared or has not occurred, and repeat step 703.

[0080] Application Example 3

[0081] This application example describes the process in which the downstream device network element 2 transmits the remotely inserted Remote Fault (RF) alarm detected at the customer-side UNI ③ position to the customer-side UNI ① position of the upstream device network element 1, as Figure 3 shown.

[0082] As Figure 8 shown in the flowchart, this embodiment will be described. Figure 8 It is the flowchart of the fault transmission from the customer-side UNI RF alarm to the line-side NNI in the present invention;

[0083] Step 801: Configure VPWS services and OAM on the upstream device network element 1 and the downstream device network element 2, configure the OAM Mapping function to be enabled on their respective customer-side UNI ports, and ensure that the corresponding service flows and OAM are normal;

[0084] Step 802: Enable the timer to poll the alarm status of the port. The timer polling period is configurable, and in this implementation example, a polling period of 10 milliseconds is used. Each time, save the currently polled alarm status and erase the alarm status of the port. The entire port alarm polling adopts the method of "reading first and then clearing";

[0085] Specifically, it includes:

[0086] Step 8021: Enable the timer task, poll the alarm register of the port every other period (this period is configurable, and in this implementation example, 10 milliseconds is used), read and save the polled alarm status information, and then clear the alarm register of the corresponding port;

[0087] Step 8022: Determine whether the alarm status of the current port is the same as the status polled last time. If they are different, proceed to Step 8023; if they are the same, proceed to Step 8024;

[0088] Step 8023: Write the alarm status of the current port into the corresponding chip (logic, NP, switch chip, CPU) register or entry, and save the alarm status information of the current port;

[0089] Step 8024: Determine whether the currently polled port is the last port of the device. If it is, end this polling; if not, continue to execute Step 8021.

[0090] Step 803: The downstream device network element 2 reads the corresponding chip register or entry of the customer - side UNI port every other period (this period is configurable, and in this implementation case, 3.3 milliseconds is used). If there is no alarm information in the chip register or entry, continue polling and repeat Step 3; if there is alarm information in the chip register or entry, continuously (when the alarm persists, every 3.3 milliseconds) send an OAM alarm message from the line - side NNI port of the device network element 2 to the line - side NNI port of the peer device network element 1 until the alarm in the chip register or entry corresponding to the customer - side UNI port of the device network element 2 disappears, and then repeat Step 803;

[0091] Step 804: The fault alarm reading module of the upstream device network element 1 checks every other period (this period is configurable, and in this implementation case, 3.3 milliseconds is used) whether it receives an OAM alarm message from the downstream device network element 2 on the corresponding line - side NNI port. If it does not receive it, continue polling. When it has not received an OAM alarm message on the corresponding port for 3 consecutive periods, it is considered that the peer alarm has disappeared, and the alarm information in the chip register or entry corresponding to the port of the device network element 1 is cleared, and Step 804 is continued; if an OAM alarm message is received, the content of the message is parsed, and the parsed alarm status is written into the chip register or entry corresponding to the port, and Step 804 is repeated;

[0092] Step 805: The upstream device network element 1 starts a timer task, polls all ports every other period (this period is configurable, and 10 milliseconds is used in this implementation case), and determines whether the port is a customer-side UNI port. If not, continue to poll the next port and repeat step 805; if so, according to the currently polled port number and slot number, read the corresponding chip register or entry, check whether there is an alarm. If there is an alarm, perform corresponding actions (RF downplug, port closing, etc.) according to the alarm type, and repeat step 805; if there is no alarm, check whether the corresponding alarm action has been performed on the current customer-side (UNI) port;

[0093] Step 806: Read the chip register or entry corresponding to the line-side NNI port every other period (this period is configurable, and 3.3 milliseconds is used in this implementation case). If no alarm is read for three consecutive periods, it is considered that the customer-side UNI alarm of the upstream device network element 1 has disappeared or has not occurred yet, and repeat step 805.

[0094] Those of ordinary skill in the art can understand that all or some of the steps in the methods disclosed above, and the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, and their appropriate combinations. In the hardware implementation, the division of the functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be executed by several physical components in cooperation. Some or all of the components may be implemented as software executed by a processor, such as a digital signal processor or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include a computer storage medium (or non-transitory medium) and a communication medium (or transitory medium). As is well known to those of ordinary skill in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassette, tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, as is well known to those of ordinary skill in the art, a communication medium typically includes computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and can include any information delivery medium.

Claims

1. A fault transparent transmission method, characterized in that, it includes: Detect the alarm status of each port of the upstream device every first preset period, and save the alarm information to the port, where the alarm information is used to indicate the alarm status; Map the alarm information to the port of the downstream device, and save the alarm information to the port of the downstream device; Read the alarm information saved in the port of the downstream device every second preset period, and perform fault handling according to the alarm information saved in the port of the downstream device; When no alarm message is received from the port of the upstream device within the third preset period, clear the alarm information of the port of the downstream device.

2. The method according to claim 1, characterized in that, The step of saving the alarm information to the port includes: Write the detected alarm information into the chip register or entry corresponding to the port.

3. The method according to claim 1, characterized in that, The step of mapping the alarm information to the port of the downstream device and saving the alarm information to the port of the downstream device includes: Map the alarm information to the port of the downstream device by sending an OAM alarm message, and write the alarm information into the chip register or entry corresponding to the port of the downstream device.

4. The method according to claim 1, characterized in that, The step of reading the alarm information saved in the port of the downstream device every second preset period and performing fault handling according to the alarm information saved in the port of the downstream device includes: Poll the port of the downstream device every second preset period; Read the alarm message in the corresponding chip register or entry through the port; Perform fault handling according to the alarm information.

5. The method according to any one of claims 2-4, characterized in that, The chip is any one of the following: a logic chip, an NP network processor chip, a switching chip, or a CPU central processing unit chip.

6. The method according to claim 1 or 4, characterized in that, The first preset period, the second preset period, or the third preset period is set by a timer.

7. A fault transparent transmission device, characterized in that, it includes: A detection module, configured to detect the alarm status of each port of the upstream device every first preset period, and save the alarm information to the port, where the alarm information is used to indicate the alarm status; A mapping module, configured to map the alarm information to the port of the downstream device, and save the alarm information to the port of the downstream device; A reading module, configured to read the alarm information saved in the port of the downstream device every second preset period, and perform fault handling according to the alarm information saved in the port of the downstream device; The reading module is further configured to clear the alarm information of the port of the downstream device when no alarm message is received from the port of the upstream device within the third preset period.

8. An electronic device, including a processor and a memory; characterized in that, A fault pass-through program is stored in the memory, and the processor is configured to run the fault pass-through program to execute the method described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that a fault pass-through program is stored in the computer-readable storage medium, wherein the fault pass-through program is configured to execute the method described in any one of claims 1 to 6 when running.

Images