Management server and network status management method
The management server addresses excessive communication traffic in network management by grouping sequential event notifications and optimizing state acquisition, enhancing efficiency in managing network states.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- FURUKAWA ELECTRIC CO LTD
- Filing Date
- 2023-04-20
- Publication Date
- 2026-04-17
AI Technical Summary
Existing network management systems incur excessive communication traffic due to frequent state change notifications from node devices, leading to inefficiencies in managing network states.
A management server that measures a predetermined waiting time after receiving an event notification, groups sequential notifications, and performs state acquisition only when no further notifications are pending, thereby reducing communication requirements.
This approach reduces communication traffic by treating sequential network state change event notifications as a series, allowing for efficient state acquisition of multiple node devices with reduced communication overhead.
Smart Images

Figure 0007847561000001 
Figure 0007847561000002 
Figure 0007847561000003
Abstract
Description
Technical Field
[0001] The present invention relates to a management server and a network state management method capable of reducing communication traffic related to obtaining the state of a network having a plurality of node devices.
Background Art
[0002] In a network having a plurality of node devices, it is necessary to manage the operating state of each node device and the connection state between each node device. A network management device that periodically performs network management of each node device has been proposed (Patent Document 1).
Prior Art Documents
Patent Documents
[0003]
Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0004] In the above Patent Document 1, since the state is periodically obtained for each node device, the communication traffic increases. On the other hand, every time an event notification of a state change such as a failure occurs is received from a node device, if the state is obtained for each node device, the state will be obtained for each of the event notifications of continuously occurring state changes, and the communication traffic for network management will increase.
[0005] The present invention has been made in view of the above, and an object thereof is to provide a management server and a network state management method capable of reducing communication traffic related to obtaining the state of a network having a plurality of node devices.
Means for Solving the Problems
[0006] To solve the above-mentioned problems and achieve the objective, the management server according to the present invention is a management server that manages the operating status of each node device and the connection status between each node device in a network having multiple node devices, and when it receives an event notification of a state change from the node device, it starts measuring a predetermined waiting time for the event notification from the time the event notification is received, and when the measurement of one of the waiting times is completed it is determined whether there are any other event notifications that are measuring the waiting time, and if there are other event notifications that are measuring the waiting time, it terminates processing for the event notification whose waiting time has finished, and if there are no other event notifications that are measuring the waiting time, it performs state acquisition for each node device.
[0007] Furthermore, the management server according to the present invention is characterized in that, in the above invention, the waiting time is longer than the state change detection time during which the node device detects a state change.
[0008] Furthermore, the management server according to the present invention is characterized in that, in the above invention, the waiting time is longer than the time obtained by adding the initialization time of the node device to the state change detection time for the node device to detect a state change.
[0009] Furthermore, the management server according to the present invention is characterized in that, in the above invention, the waiting time is longer than the maximum notification time, which is the maximum notification time among the notification times required for the event notification to reach the management server from each node device.
[0010] Furthermore, the management server according to the present invention is characterized in that, in the above invention, the waiting time is the maximum time obtained by combining one or more of the following times: the initialization time of the node device, the state change detection time for the node device to detect a state change, and the maximum notification time which is the maximum of the notification time required for the event notification to reach the management server from each node device.
[0011] Furthermore, the management server according to the present invention is characterized in that the network is an optical network that performs multi-hop communication.
[0012] Furthermore, the network state management method according to the present invention is a network state management method for managing the operating state of each node device and the connection state between each node device in a network having a plurality of node devices, characterized in that when an event notification of a state change is received from the node device, the timing of a predetermined waiting time is started for the event notification from the time of receipt of the event notification, when the timing of one of the waiting times is completed it is determined whether there are any other event notifications that are timing the waiting time, if there are other event notifications that are timing the waiting time, the processing for the event notification whose timing has ended is terminated, and if there are no other event notifications that are timing the waiting time, the state acquisition for each node device is performed. [Effects of the Invention]
[0013] According to the present invention, sequential network state change event notifications are treated as a series of event notifications, and each event notification is grouped together to perform state acquisition for each node device, thereby reducing the amount of communication required to acquire the state of each node device. [Brief explanation of the drawing]
[0014] [Figure 1] Figure 1 is a schematic diagram showing the overview configuration of a network including a management server, which is an embodiment of the present invention. [Figure 2] Figure 2 is a functional block diagram showing the configuration of the node device. [Figure 3] Figure 3 is a sequence diagram showing the process of acquiring the status of the management server when a node device goes down. [Figure 4] Figure 4 is an overall flowchart showing the procedure for obtaining the status of each node device by the management server. [Figure 5]Figure 5 is a detailed flowchart showing the processing steps for the state acquisition process shown in Figure 4. [Figure 6] Figure 6 is a sequence diagram showing the status acquisition process by the management server in the modified example 1. [Figure 7] Figure 7 is a sequence diagram showing the status acquisition process by the management server in the modified example 2. [Figure 8] Figure 8 is a sequence diagram showing the status acquisition process by the management server in the modified example 3. [Modes for carrying out the invention]
[0015] Hereinafter, embodiments for carrying out the present invention will be described with reference to the attached drawings.
[0016] <Device configuration> Figure 1 is a schematic diagram showing the overview configuration of a network 2 including a management server 1, which is an embodiment of the present invention. Network 2 has a plurality of node devices N, and communication is performed between each node device N depending on the connection status of each node device N. Network 2 is, for example, a mesh-type optical network and performs multi-hop communication. As a routing protocol that determines the communication path through the plurality of node devices N constituting Network 2, for example, the AODV (Ad hoc On-Demand Distance Vector) routing protocol is used. The AODV routing protocol is a reactive routing protocol that determines a communication path with a small number of hops for the node devices N.
[0017] The general overview of the AODV routing protocol is as follows: First, the source node device broadcasts a route request packet (RREQ) to adjacent node devices. The node device that receives this route request packet then broadcasts it to adjacent node devices other than the receiving node device, repeating this until the destination node device is reached. At this time, the cumulative relay count (hop count) is incremented for each transfer of the route request packet. Then, the destination node device unicasts a route reply packet (RREP) to the source node device for the route indicated by the route request packet with the fewest relay counts among the multiple received route request packets. Each node device temporarily stores a temporary route table including the source, destination, relay source, and relay destination when it receives a route request packet. If it receives a route reply packet within a predetermined time, it stores the temporary route table as the route table and deletes other temporary route tables. Thereby, each node device determines the communication path between the source node device and the destination node device using the route table.
[0018] Figure 2 is a functional block diagram showing the configuration of the node device N. As shown in Figure 2, the node device N has a packet relay processing unit 15 to which a storage unit 11, a control unit 12, receiving units 13-1 to 13-n, and transmitting units 14-1 to *************** are connected. The packet relay processing unit 15 transmits, according to the information stored in its header, the packets received by the receiving units 13-1 to 13-n from the corresponding transmitting units 14-1 to 14-n in response to the control of the control unit 12. The control unit 12 controls the packet relay processing unit 15 according to the route table RT stored in the storage unit 11, relays the packets, determines the optimal route, and sets the determined route table RT. Note that the receiving units 13-1 to 13-n and the transmitting units 14-1 to 14-n are paired and connected to the communication paths with other node devices N respectively, and perform transmission and reception processing with other node devices N respectively.
[0019] It should be noted that there is an omission in the English translation of the content of "transmitting units 14-1 to ***************" in the original text. Please check and correct it according to the actual situation.One of the node devices N is connected to the management server 1. Each node device N notifies the management server 1 of an event notification of a state change when the operating state of the node device N or the connection state between the node devices N changes. For example, as shown in FIG. 1, when the link between the node device NA and the node device NB goes down, the node devices NA and NB each send an event notification of a state change to the management server 1 via the node device N with which the link is established. The management server 1 that has received this event notification executes state acquisition for each node device N.
[0020] Here, when the management server 1 of the present embodiment receives an event notification of a state change from the node device N, it starts counting a preset waiting time from the time of receiving the event notification, and when the counting of one waiting time ends, it determines whether there is another event notification for which the waiting time is being counted. If there is another event notification for which the waiting time is being counted, the processing for the event notification for which the waiting time has ended is interrupted. If there is no other event notification for which the waiting time is being counted, state acquisition for each node device is executed.
[0021] FIG. 3 is a sequence diagram showing the state acquisition process of the management server 1 when the link between the node devices NA and NB goes down. As shown in FIG. 3, when the link between the node devices NA and NB goes down, the node device NA sends an event notification m1 of a state change (link down) to the management server 1. Also, the node device NB sends an event notification m2 of a state change (link down) to the management server 1.
[0022] Upon receiving event notifications m1 and m2, the management server 1 begins timing each event notification m1 and m2 by a predetermined waiting time T from the time of receipt. When the timing of the waiting time T for event notification m1 is finished, the management server 1 determines whether there are any other event notifications that are currently timing their waiting time T. In this case, since event notification m2 is also timing its waiting time T, the management server 1 terminates processing for event notification m1. Subsequently, when the timing of the waiting time T for event notification m2 is finished, and there are no other event notifications timing their waiting time T, the management server 1 sends a status acquisition message mm to each node device N to acquire the status of each node device N.
[0023] In this embodiment, instead of performing state acquisition processing for each node device N after receiving each event notification m1 and m2, event notifications m1 and m2 are treated as a series of event notifications, and state acquisition for each node device N is performed on all event notifications m1 and m2 together. This reduces the amount of communication required for acquiring the state of each node device N.
[0024] <Status acquisition process> Figure 4 is an overall flowchart showing the status acquisition process for each node device N by the management server 1. As shown in Figure 4, the management server 1 first determines whether or not a status change event notification has been received from node device N (step S101). If there is no event notification (step S101: No), the determination process in step S101 is repeated. On the other hand, if an event notification is received (step S101: Yes), the status acquisition process is executed (step S102), and the process returns to step S101 and the above process is repeated. Note that the status acquisition process in step S102 is not a subroutine, but rather a thread for the status acquisition process is started each time, and after the status acquisition process, the process ends without returning to step S102, allowing one or more threads to be running in parallel.
[0025] Furthermore, Figure 5 is a detailed flowchart showing the processing procedure for the status acquisition process shown in Figure 4. As shown in Figure 5, the management server 1 first starts timing the waiting time T from the time of receiving the event notification (step S201). Then, the management server 1 determines whether the timing of the waiting time T has finished (step S202). If the timing of the waiting time T has not finished (step S202: No), this determination process is repeated.
[0026] On the other hand, if the timing of the waiting time T has finished (step S202: Yes), it is further determined whether there are any other pending status acquisition processes (step S203). If there are other pending status acquisition processes (step S203: Yes), this process is terminated. Conversely, if there are no other pending status acquisition processes (step S203: No), the status acquisition for this event notification is performed (step S204), and this process is terminated. That is, in order to acquire the status for the event notification, a status acquisition message is sent to each node device N to acquire the status of each node device N, and this process is terminated.
[0027] <Example 1> Figure 6 is a sequence diagram showing the state acquisition process by the management server 1 in Modification 1. In Modification 1, the waiting time T is set to be longer than the state change detection time Td in which the node device detects the state change (waiting time TA).
[0028] As shown in Figure 6, when a state change (link down) occurs in node devices NA and NB, node devices NA and NB notify the management server 1 of event notifications m10 and m11, respectively.
[0029] Here, when the management server 1 receives each event notification m10 and m11, it starts timing the waiting time TA from the time of receipt of each event notification m10 and m11. Since the waiting time TA is longer than the state change detection time Td, each event notification m10 and m11 occurs within the duration of the waiting time TA. In Figure 6, since event notification m10 is notified to the management server 1 first, at the end of the waiting time TA for event notification m10, the waiting time TA for event notification m11 is still being timed, and the processing of event notification m10 is terminated.
[0030] Subsequently, at the end of the waiting time TA for event notification m11, if there are no other event notifications with waiting time TAs being measured, status acquisition for each node device N is performed at the end of the waiting time TA for event notification m11. However, in Figure 6, during the waiting time TA for event notification m11, a status change (link up) occurs for node devices NA and NB. After the status change detection time Td, event notifications m12 and m13 are notified to the management server 1 from node devices NA and NB, respectively, and waiting time TAs for each event notification m12 and m13 are being measured. Therefore, at the end of the waiting time TA for event notification m11, the waiting time TAs for event notifications m12 and m13 are still being measured, and processing for event notification m11 is terminated.
[0031] Similarly, at the end of the waiting time TA for event notification m12, the waiting time TA for event notification m13 is still being timed, and processing for event notification m12 is terminated. Then, at the end of the waiting time TA for event notification m13, since there are no other event notifications with waiting time TAs being timed, at the end of the waiting time TA for event notification m13, the management server 1 sends a message mm to each node device N to obtain the status of each node device N.
[0032] In this modified example 1, the waiting time TA is made longer than the state change detection time Td. Therefore, even if communication becomes unstable due to bending of the communication cable or other reasons and the link between connected node devices goes down, the event notifications from the connected node devices NA and NB are grouped together as a series of event notifications and the state acquisition for node device N is performed in one go. This reduces the amount of communication required to acquire the state for node device N.
[0033] <Modification 2> Figure 7 is a sequence diagram showing the state acquisition process by the management server 1 in Modification 2. In Modification 2, the waiting time T is set to be longer than the sum of the initialization (startup) time Ts and the state change detection time Td of the node device N after the node device N has stopped (waiting time TB).
[0034] As shown in Figure 7, if node device NB stops, node device NA, which was connected to node device NB, will notify management server 1 of a state change (link down) event notification m20 after the state change detection time Td in which node device NA detects the state change.
[0035] Subsequently, node device NB is started up, and after initialization time Ts, node device NB completes its initialization. This initialization of node device NB establishes a link between node device NA and node device NB, and node device NA notifies management server 1 of a state change (link up) event notification m21 after a state change detection time Td from the link up. Similarly, node device NB, upon establishing a connection with node device NA, notifies management server 1 of a state change (link up) event m22 after a state change detection time Td from the link up.
[0036] Here, when the management server 1 receives each event notification m20, m21, and m22, it starts timing the waiting time TB from the time of reception of each event notification m20, m21, and m22. The waiting time TB is set to be longer than the time obtained by adding the state change detection time Td to the initialization time Ts of the node device N. Therefore, when the timing of the waiting time TB for event notification m20 ends, the timing of the waiting time TB for event notifications m21 and m222 is still being timed, so processing for event notification m20 is terminated. Similarly, when the timing of the waiting time TB for event notification m21 ends, the timing of the waiting time TB for event notification m22 is still being timed, so processing for event notification m21 is terminated. Subsequently, when the timing of the waiting time TB for event notification m22 ends, there are no event notifications timing the waiting time TB, so at the end of the waiting time TB for event notification m22, the management server 1 sends a message mm to each node device N to obtain the status of each node device N.
[0037] In this modified example 2, the waiting time TB is made longer than the time obtained by adding the state change detection time Td to the initialization time Ts of node device N. As a result, event notifications that occur between the event notification for the shutdown of node device N and the event notification for the link up due to the startup (restart) of node device N are combined and performed as a single state acquisition process. Specifically, event notifications m20, m21, and m22 are combined as a series of event notifications and a single state acquisition for node device N is performed. This reduces the amount of communication required for state acquisition for node device N.
[0038] <Variation 3> Figure 8 is a sequence diagram showing the status acquisition process by the management server 1 in Modification 3. In Modification 3, the waiting time T is set to a time (waiting time TC) that is longer than the maximum notification time Tx, which is the maximum notification time required for an event notification to reach the management server 1 from each node device N. The maximum notification time Tx is, for example, the value obtained by multiplying the transfer time between adjacent node devices by the maximum number of transfers within the network 2 via multi-hop.
[0039] As shown in Figure 8, node devices NA and NB experience a state change (link down) and notify management server 1 of event notifications m31 and m32, respectively. Furthermore, node device NC experiences another state change independently after event notifications m31 and m32 and notifies management server 1 of event notification m33.
[0040] Here, when the management server 1 receives each event notification m31, m32, and m33, it starts timing the waiting time TC from the moment of receipt of each event notification m31, m32, and m33. Even if state changes occur simultaneously for each event notification m31 to m33, the timing of reception by the management server 1 will differ depending on the number of hops in network 2. The waiting time TC is designed to absorb this difference in notification times for each event notification m31 to m33, and instead of individually acquiring the state for many event notifications that occur in a short period of time, it performs only one state acquisition.
[0041] Specifically, at the end of the waiting time TC for event notification m31, the waiting time TCs for event notifications m32 and m33 are still ticking, so processing for event notification m31 is terminated. Subsequently, at the end of the waiting time TC for event notification m32, the waiting time TC for event notification m32 is still ticking, so processing for event notification m32 is terminated. Furthermore, at the end of the waiting time TC for event notification m33, there are no other event notifications, so status acquisition is performed at this point.
[0042] In this modified example 3, the waiting time TC is made longer than the maximum notification time Tx, so that status acquisition can be performed only once for multiple event notifications associated with status changes that occur at least almost simultaneously. This reduces the amount of communication required for status acquisition to the node device N.
[0043] The waiting time T may be the maximum time obtained by combining one or more of the following: the node device initialization time Ts, the state change detection time Td, and the maximum notification time Tx.
[0044] Furthermore, although the above embodiments and modifications were described using an optical network performing multi-hop communication as an example, the network 2 is not limited to this, and can be any network connected by multiple node devices N. It can also be applied to wired networks and wireless networks other than optical networks, and may even include some wired networks and wireless networks other than optical networks.
[0045] Although embodiments and modifications of the invention made by the present inventors have been described above, the present invention is not limited by the descriptions and drawings that constitute part of the disclosure of the present invention in this embodiment. That is, all other embodiments, examples, and operational techniques made by those skilled in the art based on this embodiment are included in the scope of the present invention. [Explanation of symbols]
[0046] 1. Management Server 2 Network 11 Storage section 12 Control Unit 13-1~13-n Receiver 14-1~14-n Transmitter 15. Packet relay processing unit m1, m2, m10, m11, m12, m20, m21, m31, m32, m33 Event Notifications mm Message N, NA, NB, NC node devices RT routing table T,TA,TB,TC Standby time Td State change detection time Ts Initialization Time Tx maximum notification time
Claims
1. A management server that manages the operating status of each node device and the connection status between each node device in a network having multiple node devices, A management server characterized in that, upon receiving an event notification of a state change from the node device, it starts timing a predetermined waiting period for the event notification from the time of receipt of the event notification, determines whether there are other event notifications timing a waiting period when the timing of one of the waiting periods has finished, terminates processing for the event notification when there are other event notifications timing a waiting period when the timing of the waiting period has finished if there are other event notifications timing a waiting period if there are other event notifications timing a waiting period if it performs state acquisition for each node device.
2. The management server according to claim 1, characterized in that the waiting time is longer than the state change detection time for the node device to detect a state change.
3. The management server according to claim 1, characterized in that the waiting time is longer than the initialization time of the node device plus the state change detection time for the node device to detect a state change.
4. The management server according to claim 1, characterized in that the waiting time is longer than the maximum notification time, which is the maximum notification time among the notification times required for the event notification to reach the management server from each node device.
5. The management server according to claim 1, characterized in that the waiting time is the maximum time obtained by combining one or more of the following: the initialization time of the node device, the state change detection time for the node device to detect a state change, and the maximum notification time which is the maximum of the notification time required for the event notification to reach the management server from each node device.
6. The management server according to any one of claims 1 to 5, characterized in that the network is an optical network that performs multi-hop communication.
7. A network state management method for managing the operating status of each node device and the connection status between each node device in a network having multiple node devices, A network state management method characterized in that, when the management server receives a state change event notification from the node device, it starts timing a predetermined waiting time for the event notification from the time of receipt of the event notification, determines whether there are other event notifications timing a waiting time when one of the waiting times has finished, terminates processing for the event notification when there are other event notifications timing a waiting time if there are other event notifications timing a waiting time if there are other event notifications timing a waiting time if there are other event notifications timing a waiting time if there are no other event notifications timing a waiting time if it performs state acquisition for each node device.
Citation Information
Patent Citations
Network managing device
JP2000259520A
Embedded reactive and proactive intelligence
US20090048995A1
Relevant Alert Delivery In A Distributed Processing System
US20120110161A1