JPS63138848A - Networm fault management system - Google Patents

Abstract

PURPOSE:To allow a small sized computer to recover a fault properly even with complicated network constitution or revision of constitution by using a network constitution table provided to a control management station so as to check the local of the management station. CONSTITUTION:A digital multiplexer or a multiplex store and forwarding proces sor 4 applying the control of a local state supervision and changeover of a network is connected to a centralized management station (center) 1 applying centralized control of the entire network via a control line 5. The center 1 is operated by a fault management task comprising a polling task to check the state of the station 4 and a main task or the like giving a constitution revision request to a node to apply fault detection and fault recovery. The state of the local station 4 to be received is discriminated quickly by the task and when a fault is detected, the constitution revision request instruction such as changeover is given to the relevant station 4.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a network management system, and particularly to a failure detection nine-recovery blade type suitable for a network failure management system.

[Conventional technology]

For fault recovery in the network, after detecting the location of the fault,
Switching (routing) is generally performed to avoid the location where the failure occurs. In the conventional method, each node in the network has a routing table, and the switching route in the event of a failure is written in the table in advance. Therefore, route selection when a failure occurs can be achieved by referring to the table.

However, when the network becomes complex, modifying or creating a new routing table is not always easy to maintain because it requires modifying the routing tables of most nodes or creating many new tables. is not good.

In addition, since failure recovery is routed in a distributed manner at each node, a difference in recovery time between reads may cause another failure, or the synchronization operation of adjusting the recovery time requires a large amount of processing time and complicated procedures. There were disadvantages to doing so.

Therefore, a relatively large computer is required to manage and control each node, and as the scale of the network increases, the cost increases.

[Problem that the invention seeks to solve]

The above-mentioned conventional technology can perform failure recovery after failure detection when the network configuration becomes complex, and can perform failure recovery under the control of a small computer.
It becomes difficult to do it quickly. That is, under the control of a small computer, it took time to switch lines for failure recovery, and there was a risk that a failure would occur at another location due to a lag in the switching time.

Furthermore, if the relationship between networks changes due to expansion or combination of network configurations, failure recovery becomes more complicated.

There are problems in that it may become difficult to operate the network securely, and the network configuration cannot be easily changed.

An object of the present invention is to appropriately and quickly perform failure recovery under the control of a small computer even if the network configuration becomes complicated or there is a configuration change such as expansion.

[Means for solving problems]

The purpose of the above is to prepare a two-dimensional matrix table called the network configuration table at the center (network general management station), and to track configuration changes by constantly rewriting this table to understand the relationship between the network elements. This is achieved by

Failure detection involves checking the status of each node (local management station of the network) represented by the address in this network configuration table (
This is done by polling).

Fault recovery is performed by the center issuing a configuration change request command such as switching to nodes that are structurally related to the location where the fault occurred, and simultaneously switching the related locations at a specified time. If recovery is not possible, a message is output and maintenance personnel perform recovery.

[Effect]

The center has a polling task that checks the status of nodes, a main task that issues configuration change requests to nodes for failure detection and recovery, and an initialization task that creates configuration tables and starts polling and main tasks. It operates through three fault management tasks: . Thereby, the status received from the node can be quickly determined and the configuration table can be used to appropriately issue configuration change requests to the node.

By preparing the above configuration table at the node, the node can leave the determination of the status of the lines and devices connected to the node to the center, and the recovery time due to switching can be executed according to the center's instructions, which simplifies the process. This makes it possible to reduce processing time and facilitate execution on a small computer.

〔Example〕

An embodiment of the present invention will be described below with reference to FIGS. 1 to 9.

FIG. 1(a) shows the network configuration of a computer/communication system to which the present invention is applied. A digital multiplexing device or multiplexing and distribution device 4 that monitors the local state of the network and controls switching, etc., called a node.

A station 1 called a center is provided which monitors the nodes via a control line 5 and performs overall control of the mesh body. A plurality of low/medium speed lines 6 and a plurality of high speed lines 7 are connected to each node 4 and can be switched. Further, a satellite communication earth station 8 may be connected to the high-speed line side, and a satellite line 9 may be used. Note that a console 2 and a disk 3 are connected to the center for node monitoring and control.

FIG. 1(b) is a schematic illustration of FIG. 1(a). Here, each node is given a hexadecimal address.

In the present invention, when a failure occurs in a line or the like due to a failure, commands and status information are exchanged between the node that monitors the state of the line and the center to smoothly perform failure recovery. In other words, it is possible to quickly switch from a failed line to another line. This is because the nodes perform failure recovery within the specified time required by the center. Therefore, it becomes possible to operate the network safely.

A method for implementing the present invention will be explained in order below.

FIG. 2 shows basic commands used for failure recovery according to the present invention and control symbols used when transmitting node status (t). This symbol is represented by a hexadecimal number called a code.

Specifically, activation request 10 is a command requesting activation (line establishment) of a designated address line, disconnection request 11 is a request to disconnect the designated address line, and manual request is a request for manual checking and maintenance of the designated address line. shows. Status transmission 13 is used for node status transmission.

FIG. 3 is a network configuration table used by the center to know the current configuration of the network when detecting and recovering from a network failure. The configuration table is represented as a two-dimensional matrix, with one row per row.
Column 4 lists IN, that is, the address of the node connected to the line input to each node, and column 15 lists OUT, that is, the address of the node connected to the line output from each node. For example, in the case of 7-DoB in FIG. 1(b), the line input from node A to node B is shown as (IN, 0UT) = (AB, AA)18, and the current state of this line is shown here. That is, information such as whether or not cutting is in progress is entered in hexadecimal numbers. Conversely, 17 indicates a line entering node A from Nord B.

The state of Node B itself is (IN, 0UT) = (AA, AA
), that is, indicated by 16. 19 indicates the status of node A itself.

The configuration table is created from data input from the console's keyboard and stored on disk before the center starts the disaster recovery process.

Figure 4(a) shows a network configuration of three nodes 21, 22, and 23, and when the center detects a fault 20 in the line between nodes 22-23, what kind of configuration change request does the center make to each node? This is an example explaining how to issue. here,
Figure 4 (→ shows only the lines connected to each node from other nodes for simplicity, but in reality, each node locally manages the computers 2 communication devices, terminals, etc. connected to it. There are many lines connected to it.

Each node is given a hexadecimal address in the center's configuration table before the center begins the disaster recovery process. In FIG. 4(a), $AB, $AA, and $35 are attached to the node 21°22.23. In this embodiment, this address has a length of 1 byte, but it can be expanded to 2 bytes or more in order to change the size of the configuration table.

Thereafter, the center and each node identify the center and each node by reading this address.

FIG. 4(b) shows that when the center detects a faulty line 22-23, the center sends a change request command to each node, and each node sends a status to the center upon receiving the change request command. This shows the contents of the commands used when doing this.

A change request to the node 22 will be explained as an example. First, the node 22 takes out the instruction whose address 24 is $AA't and decodes it.

This is done by starting tasks on the nodes.

The decoding is performed by reading the configuration change part from the IN23, 0UT26 part of the instruction, and reading the configuration change designated time and the configuration change (switching) method from the CNTL part 27 and TIME part 28.

When the configuration change point is (IN, 0UT) = (AB, AA), it goes from node B ($AA) to node A ($AB
), when (IN, 0UT) - (35, AA), the line goes out from node B ($AA) and goes to node C ($35).
It can be read by indicating the line entering the line.

The configuration change designated time is read from the time of TIME. 1T
If the byte length of IME is 1 byte.

It is possible to identify 256 types of times from $00 to $FF, and for example, if you differentiate one day every 10 minutes, you only need 144 types, so there is no problem between the center and the nodes as to which time corresponds to which hexadecimal number. If it is determined before starting the recovery process, the specified configuration change time can be read. A more detailed time can be specified by making the byte length of TIME28 larger than 1 byte.

For the configuration change (switching) method, read CNTL27.
If N, activate the line at the specified time.

When it is OFF, the 7-mode switching program is made to disconnect the line at a specified time.

In this case as well, the types of commands that the center sends to the nodes can be increased depending on how the byte length of the CNTL 27 is determined. In other words, in this embodiment, ON and OF'F
For example, in order to share the load of each line connected to a node, it is necessary to instruct in hexadecimal stages how much of the capacity of one line should be switched between ON and OFF. It is also possible to do the following.

On the other hand, upon receiving a configuration change request from the center, the node performs a status check test on the configuration change location and sends the result to the center. C in this case
NTL27 is a hexadecimal code (
expressed in numbers). This code (number) may be of any value as long as it is determined before starting the failure recovery process between the center and the node. In TIME, enter a hexadecimal code indicating the time when the status check was performed. (IN.

0UT) is sent to the center address (assumed to be $01), so IN23 is $01.

0UT26 contains the node address (
8AA). Therefore, the status from Node B contains (IN, 0UT) = (01, AA).

In the case of status transmission, as shown in FIG. 4(b), a 5TAT part 29 is added after TIME, and
Enter the node status, check/test results, and obtained status in this part. The byte length of 8TAT is set to be large enough to store the status.

FIG. 5 shows a command structure 32 when transmitting the configuration change request determined in FIG. 4(b) from the center to a node.

A header 30 called HDR is attached at the beginning, and it can be identified that this is an instruction used in the present invention. HDR may be any hexadecimal code as long as it can be distinguished from other hexadecimal codes such as controls, commands, data, etc. necessary for network management. next F
LN31 indicates the byte length of the entire instruction. The size of the FLN area should be large enough to represent the size of possible instructions. A node can know how long an instruction lasts based on the contents of the FLN, and this information is used when decoding the instruction. After the FLNO, instructions indicating the request shown in FIG. 4(b) continue for each instruction length unit. The status 33 sent from the node to the center is the configuration 3 of the command sent from the center to the node.
It is almost the same as 2, but the difference is that there is an area after CNTL to enter the status 8TAT29.

In both cases of commands and status, the configuration is transmitted in a frame called a frame as shown in FIG. 5, so these will be referred to as a configuration change request frame 32 and a status frame 33.

FIG. 6 is a diagram showing how the center causes nodes to recover from the failure when a failure occurs in the network. FIG. 6 shows frame transmission between the center and the nodes as time passes from top to bottom. Hereinafter, a step-by-step explanation will be given in the order of 34-42.

34 The center periodically updates the node status (status)
This is called polling, which checks the status of the node and learns that there is a failure.

35 The center determines whether or not the failure can be recovered within a certain period of time, and if it is recoverable, it transmits a configuration change request frame to the node in question and nodes that have a configurational relationship in the vicinity. Here, the time allowed for one recovery is determined as a keyboard input parameter at the beginning when the center executes the fault management task. Nodes that have a structural relationship are determined based on the configuration table currently held by the center. If the failure is irrecoverable, a manual request frame is sent to the corresponding node and surrounding nodes that have a structural relationship. do. A node that receives this frame knows from the message output that failure recovery must be performed by maintenance personnel.

36 The node that receives the configuration change request frame from the center checks where the configuration has changed, starts a hardware check program to test the configuration change, and reads the current status.

This result is then communicated to the center by sending a status frame.

37.38 When the center receives the status/7-frame, it determines whether there is a problem with the result. The processing when there is a failure (double failure) is the same as in 35. In the normal case, the center does not make any requests to the relevant node until the specified time for configuration change, and only performs polling.

39.40 Even though the status of 37 and the result of 7 frames were normal by the specified time of configuration change, some kind of failure may be discovered when polling the relevant node. The processing in that case is the same as 35.

41 When the specified configuration change time arrives and the node starts the hardware switching program and changes the configuration, the node starts the hardware check program to check whether the configuration change was performed correctly and the failure has been recovered. , tests the configuration changes, and reports the results to the center by sending a status frame.

42 When the center receives the status frame, it determines whether there is a fault in the result. If there is no failure, it is assumed that the configuration change was completed at the specified time, and if there is a failure, the specified time has already passed, and a manual request frame is sent to the corresponding node as an unrecoverable failure.

FIG. 7 is an algorithm of the center that executes the failure recovery process of FIG. 6. It is composed of three fault management programs (tasks) depending on the processing group. The three tasks are the initialization task (7th
Figure (a)), POLL that performs node polling
(Figure 7(b)).

MAIN (Figure 7 (C)
), is. In addition, in order for the center to read the node status and detect failures, 5TATU8 (Figure 7(d)
) using subroutines. [- In order to operate these tasks, file management and input/output management such as frame memory 2 creation, transmission, and reception, task management for starting tasks, and timer management for taking e-time logs, etc. is necessary. These are typically executed by the center's operating system.

Next, the operation of the center will be explained according to FIG.

The center is activated by executing an initialization task (0) from the keyboard installed in the center. The initialization task then requests configuration definition input on the screen, and upon completion of this input, the center configuration table is created. Furthermore, parameters necessary for failure recovery are inputted, and when all inputs are completed, the MAIN task is activated (45). Initially, the task is in a dormant state (52) because there is no status frame reception or configuration change request from the node. When the activation of the MAIN task is completed, the POLL task is activated periodically (46). The activation cycle depends on the number of constituent nodes, failure recovery request response time, etc., and is determined by parameter input. When these preparations are completed, the initialization task disappears (47).

For example, suppose that a failure is detected by polling according to FIG. Failure detection is executed by the 5TATUS subroutine (62). That is, in FIG. 7(d), the status is not normal (64). At this time, it is determined whether the obtained status is a recoverable failure (6 checks), and if recovery is possible within a certain time determined by parameter input (70), a configuration change request (71) is issued. , and other unrecoverable failures (74) or those that require a long recovery time (72) will require a manual request (73).The prediction of failure recovery time is based on the accumulation of empirical data.Therefore, Even if you think that the failure recovery time is long, you may actually be able to recover from the failure easily, or conversely, even if you think that the failure recovery time is short, you may mistakenly think that it is actually impossible to recover from the failure. By sending a request frame (60), the node's maintenance status is easily recovered.Also, in the latter case, the center sends a configuration change request frame (58), and the node attempts to change the configuration. At that time, the status check (
When the center receives (53) the result of step 79), it learns (74) that the node side was unable to recover from the failure. As a result, the center in turn sends a manual request frame (59) L, and the failure of the node is recovered by maintenance personnel. In other words, in either case, it is possible to deal with the failure.

When a configuration change request (71) or manual request (73) is issued by polling, the dormant task MAIN (5
2) is activated, learns that a request is rare (54), and transmits a frame that meets the request to the polled node and nodes that have a structural relationship in the vicinity thereof (58, 59). After the transmission, it becomes dormant again (52).

Upon receipt of a configuration change request frame or a manual request frame (1 (76)), the node sends a status frame (80) to the center. When the center receives this status frame, it Task MA I N (52) starts and the contents of the status frame are determined by the 5TATU8 subroutine (55)
do. If a configuration change request or manual request is issued as a result of the judgment, MAIN (52) is suspended after 1 judgment.
The node immediately restarts (-), receives the status frame, and transmits the frame matching the request to the node 9 and the nodes that are structurally related to it in the periphery. In this case, the compositional relationship is.

Check the configuration table in the center.

The above is the failure recovery operation of the center.

FIG. 8 shows reference to the configuration table when the center polls a node. The polling pointer (75) is used for reference, and each node (14) in the IN is
), polling of the OUT peripheral nodes (15) entering there is performed in order. The polling order may be the address order (76) as shown in the figure.

Special algorithms may be used.

FIG. 9 shows an algorithm for carrying out the node failure recovery process. Unlike the center, the processing is simplified to just one task. This is because the center performs all status determination and the like.

It's 9, and the K that runs the node algorithm is.

A check program that executes a loop test of connected hardware, a hardware switching program that executes configuration changes, status frame transmission and request frame reception, storage of information on configuration changes (nodes, etc.), and timer management for timeouts. etc., an operating system is required as well as the center.

Next, the operation of the node will be explained according to FIG. A node task is activated (76) upon reception of a configuration change request frame or a manual request frame.

Note that polling from the center requires hardware
Only the status is read and no tasks are started.

In the case of receiving a manual request frame, the task simply outputs a message (87) and pauses (86).

On the other hand, in the case of receiving a configuration change request frame, the configuration change time is read from the frame, and a timer is started so that the time is a timeout (78). Next, a configuration change location (node) is read from the frame, and a hardware check/test of that location is executed by a program σ9).

Then, the resulting status is read, a status frame 1- is created, and it is sent to the center β0).

Thereafter, the process waits for configuration change (81) until the configuration change time times out. If the center detects a failure in the status frame sent by the node during this time, or if a failure is detected by polling,
A configuration change request frame or manual request frame is sent from the center. As a result, the node releases the configuration change waiting state (82)L, and in the case of receiving a configuration change request frame, resets the configuration change time again (78).
Run status check tests for configuration changes (
79) After transmitting a status frame (80), the system enters the configuration change area (81). In the case of receiving a manual request frame, the task is suspended (86) after outputting a message (89).

If there is no request while waiting for a configuration change, a timeout occurs at the configuration change designated time (83)L, and the specified configuration change location is changed by the hardware switching program (84). After execution, execute the status check test of the configuration change location again, and send the result to the center as a status frame (85)L
, the node's tasks are paused (86). As a result of this status frame, even if the center detects a failure, it is always an unrecoverable failure whose override time has already passed, resulting in the node receiving a manual request frame, which causes the node to The task is restarted (76), but immediately halts (86) after outputting the message (86).

The above is the failure recovery operation of the node.

〔Effect of the invention〕

According to the present invention, the network central management station detects a network failure and sends a switching request for failure recovery based on the status information of the local network management station, so that it is possible to change or expand the network configuration. On the other hand, the network's local management station does not know anything about it.
Checking and switching hardware can be performed only by instructions from the central management station. Furthermore, since the switching time is specified by the central management station, synchronization processing for switching is not required at the local management station of the network.

Therefore, when changing or expanding the network configuration, it is only necessary to change the configuration definition of the network general management station, and there is no need to change the local management station, making it easy to change or expand the network configuration.

In addition, there is no need to synchronize the switching of 5 failure detection and tS damage recovery, which simplifies the processing at the local management station of the network.

Processing time can be shortened, improving economic efficiency.

[Brief explanation of the drawing]

Fig. 1 is a network configuration diagram of an embodiment of the present invention, Fig. 2 is a request command, types of symbols in the CNTL section of status, Fig. 3 is a center configuration table, and Fig. 4 is a diagram showing a failure in the network. Configuration change request CNTL section and status/CNTL
FIG. 5 is a configuration diagram of a configuration change request frame and a status frame, and FIG. 6 is a diagram showing the exchange of requests and status in the failure recovery process between the center and nodes.
In Figure 7, (a) represents the center initialization task %(
An example of the center's failure recovery algorithm, in which b) represents a polling task, (C) a main task that performs status determination and request transmission, and (d) a 5TATUS subroutine that determines request transmission as a result of status determination. FIG. 8 is an explanatory diagram of a method of polling all nodes at the center, and FIG. 9 is an example of a node failure recovery algorithm.

Claims (1)

[Claims] 1. In a network configuration that has a local management station and a central management station, the central management station is provided with a network configuration table that defines the network configuration, and the network configuration table is used to control the local management station. A network fault management method that detects faults by checking the status of the network. 2. As a result of the above failure detection, if a failure occurs, the central management station will specify a time to the local management station to switch lines and equipment to the location where the failure has occurred and to locations around it that are structurally related. 2. The network failure management method according to claim 1, in which a request is issued and simultaneous switching is performed at a specified time.