Communication control device

Abstract

In the present invention, when communication is performed between two nodes by using a main path (active system) and a backup path (standby system), and network performance of each of the paths is ascertained by test packet transmission, an increase in processing load due to the test packet transmission and occurrence of communication interruption due to delay of failure detection are prevented. The test packet transmission frequency of the active system and the test packet transmission frequency of the standby system are individually and dynamically controlled. The test packet transmission frequency of the active system is set to be smaller than the test packet transmission frequency of the standby system. Constants of the transmission frequencies of the active system and the standby system are managed by using a slot schedule management table. The test packet transmission frequency of the standby system is increased when an RTT change different from a normal time is detected in the active system. When routing switching occurs, the test packet transmission frequency of the standby system is reduced in advance so that routing processing can be preferentially performed.

Description

communication control device

[0001] The present invention relates to a communication control device that can be used for data communication between two points, a first node and a second node, connected via a communication network, and in particular to a communication control device that supports a redundant communication path including a main path and a backup path and has the function of measuring the network performance between the two points.

[0002] For example, various communication equipment used in the fifth-generation mobile communication system (5G) must realize ultra-high-speed, large-capacity data communication over various communication networks. Also, to maintain stable communication between two points on a communication network, it is necessary to measure the bidirectional network performance between these two points.

[0003] Protocols used to measure such network performance include TWAMP (Two-Way Active Measurement Protocol) disclosed in Non-Patent Document 1, STAMP (Simple Two-Way Active Measurement Protocol IETF RFC 8762), OWAMP (A One-Way Active Measurement Protocol), etc.

[0004] When using such a protocol, network performance is measured at the application layer, so it can be effectively used to measure the performance of real-time applications such as voice and video.

[0005] On the other hand, there is a technology called link aggregation (LAG) that bundles multiple physical NICs (also called network interface cards or network adapters) installed in a server or the like and uses them as a single virtual NIC (see, for example, Non-Patent Document 2). This makes it possible to improve fault tolerance, etc.

[0006] Another method for configuring link aggregation across two network switches is MLAG (Multi-chassis link aggregation), which allows two devices to virtually behave as one, taking over in the event of a failure.

[0007] Furthermore, as disclosed in Patent Document 1, a technique for a mobile terminal is known in which the polling interval of a transceiver is variably controlled based on the presence or absence of spatial movement of the mobile terminal detected by a motion sensor.

[0008] JP 2010-81084 A

[0009] K. Hedayat et al., "A Two-Way Active Measurement Protocol (TWAMP)", Network Working Group, RFC 5357. "Teaming Link Aggregation", "As a Network Engineer", [online], 2023 / 07 / 12, Internet<URL:https: / / www.infraexpert.com / study / etherchannel1.html>

[0010] When using the TWAMP protocol, for example, as shown in Fig. 1, two devices (A and B) 100 and 200 are prepared and connected via a communication network 300. The device 100 includes a control client 101 and a session sender 102 as a TWAMP controller. The device 200 includes a server 201 and a session reflector 202 as a TWAMP responder.

[0011] In the TWAMP protocol, first, a connection between the two devices 100 and 200 is set up in communication (TWAMP-Control) between the control client 101 and the server 201. Second, in communication (TWAMP-Test) between the session sender 102 and the session reflector 202, the session sender 102 sends and receives a UDP test packet. After receiving the UDP test packet, the session reflector 202 replies with a measurement packet. Finally, the connection is terminated in communication (TWAMP-Control) between the control client 101 and the server 201.

[0012] Furthermore, when link aggregation technology is used, a communication system configured as shown in Fig. 2 is used. In the example shown in Fig. 2, a physical machine 110 and a network switch 210 are connected via a communication network 310. The physical machine 110 also has multiple physical NICs 121 and 122 as a communication interface 120. Similarly, the network switch 210 also has multiple physical NICs.

[0013] 2, the physical machine 110 bundles and uses multiple physical NICs 121 and 122, allowing the use of a single broadband link for communication between the physical machine 110 and the network switch 210. For example, if the two physical NICs 121 and 122 each have a communication performance of 1 Gbps, a single link with a communication performance of 2 Gbps can be used.

[0014] On the other hand, when using MLAG technology, for example, as shown in Figure 3, multiple devices (MLAG peers 401, 402) are connected to an MLAG client 403 via a communication network 320 including multiple switches and links bundled by link aggregation.

[0015] In a communication system configured as shown in Figure 3, the MLAG client 403 can use multiple devices virtually as a single device by switching between them. For example, among the multiple devices, the device connected via an active link can be treated as a normal device (main device), and the device connected via an inactive link can be treated as a backup device. This makes it possible to quickly switch between the main device and the backup device in the event of a link failure or device failure.

[0016] On the other hand, when a protocol such as TWAMP is used, test packets P01, P02, ..., P0n, P11, P12, ..., P1n are normally transmitted on the data plane between the session sender 102 and the session reflector 202, as shown in Figures 4 and 5. The receiver of each test packet updates the timestamp and sequence number to measure the delay time (RTT), packet loss, jitter, number of hops, TTL (Time To Live), and processing time.

[0017] Generally, the test packets are transmitted at a constant interval. Fig. 4 shows an example of a communication state when the test packet transmission interval T01 is relatively long, and Fig. 5 shows an example of a communication state when the test packet transmission interval T02 is relatively short.

[0018] In the example shown in Fig. 4, the test packet transmission interval T01 is long, so it takes a long time for the session sender 102 to detect the abnormality using the test packet P1n after the occurrence of the failure X1. On the other hand, in the example shown in Fig. 5, the test packet transmission interval T02 is short, so the time required for the abnormality to be detected using the test packet after the occurrence of the failure X2 is reduced.

[0019] 5, the test packet transmission interval T02 is short, which increases the load on the session sender 102 for processing the test packets, and is expected to adversely affect processing other than that of the test packets. At the same time, the test packet transmission interval T02 is short, which increases the load on the session reflector 202 for processing the test packets, and is expected to adversely affect processing other than that of the test packets.

[0020] As such, there is a trade-off between the test packet transmission interval and the software processing load. If test packets are sent frequently to prioritize anomaly detection, the software processing load of the node increases. In particular, if anomaly detection on the backup route is delayed or not detected at all in a redundant configuration such as LAG, there is a risk of communication being interrupted after route switching in the event of a failure on the main route.

[0021] Generally, when sending test packets, it is assumed that each test packet will be sent at the timings shown in Figures 6 and 7, in accordance with the provisions of IETF RFC4656, Sections 3.5 and 3.6. Figure 6 shows an example of "slot type 1" (fixed interval), and Figure 7 shows an example of "slot type 0" (interval determined using exponentially distributed pseudorandom numbers).

[0022] The request session message when establishing a test session includes parameters for the slot type and the test packet transmission interval. There are two slot types: Type 0 and Type 1. Type 0 indicates that exponentially distributed pseudo-random numbers are used, while Type 1 indicates that a fixed amount is used. The parameter for the test packet transmission interval is a timestamp ( <timestamp>) represents

[0023] When transmitting each test packet, time slots SL1, SL2, ..., SLn appear in chronological order from start time t0 as shown in Figures 6 and 7. In the case of "slot type 1," test packets Pt1, Pt2, ..., Ptm are transmitted at a fixed time interval Ts from the start time of each slot as shown in Figure 6.

[0024] In the case of "slot type 0," test packets Pt1, Pt2, ..., Ptm are transmitted at time intervals Tx1, Tx2, ..., Txm from the start of each slot, as shown in Figure 7. Here, the magnitude of each time interval Tx1, Tx2, ..., Txm is determined as a time that is exponentially distributed with the average timestamp value. That is, in the example shown in Figure 7, the transmission intervals of test packets Pt1, Pt2, ..., Ptm vary according to pseudo-random numbers.

[0025] As mentioned above, there is a trade-off between the transmission interval of test packets and the software processing load. Sending test packets frequently, prioritizing anomaly detection, increases the software processing load of the node. In particular, if anomaly detection on the backup route is delayed or not detected at all in a redundant configuration such as a LAG, there is a risk of communication interruption after route switching in the event of a failure on the main route. However, the above problem cannot be solved by using either the control shown in Figures 6 and 7.

[0026] The present invention has been made in consideration of the above-mentioned circumstances, and aims to provide a communication control device that performs data communication between two points, a first node and a second node, connected via a communication network, and that is capable of appropriately transmitting test packets in accordance with the operating status of the actual communication system when measuring network performance between the two points by utilizing a redundant communication path including a main path and a backup path.

[0027] The communication control device of the present invention is a communication control device that can be used for data communication between two points, a first node and a second node, connected via a communication network, and comprises: a communication unit that corresponds to a redundant communication path including a main path and a backup path; a test packet transmission unit that sends and receives specified test packets to measure network performance in both directions between the two points; and a transmission interval control unit that dynamically changes the transmission intervals of the test packets on the main path and the backup path, wherein the transmission interval control unit controls the transmission frequency of the test packets on at least the main path to be lower than the transmission frequency of the test packets on the backup path.

[0028] According to the communication control device of the present invention, data communication between a first node and a second node connected via a communication network is performed, and a redundant communication path including a main path and a backup path is used to measure network performance between the two points. The device appropriately transmits test packets according to the actual operating conditions of the communication system. Specifically, the device controls the transmission frequency of the test packets on the main path to be lower than the transmission frequency of the test packets on the backup path. This reduces the processing load on the main path associated with measuring network performance, preventing performance degradation of processes other than network performance measurement. Furthermore, the device transmits test packets relatively more frequently on the backup path, making it possible to determine with higher reliability that the backup path is free of problems than the main path. This improves availability and fault tolerance after switching the communication path between two nodes from the main path to the backup path.

[0029] FIG. 1 is a block diagram showing an example of the configuration of a communication system using the TWAMP protocol. FIG. 2 is a block diagram showing an example of the configuration of a communication system using link aggregation technology. FIG. 3 is a block diagram showing an example of the configuration of a communication system using MLAG technology. FIG. 4 is a time chart showing Example 1 of the transmission operation of a test packet between a session sender and a session reflector when using a protocol such as TWAMP. FIG. 5 is a time chart showing Example 2 of the transmission operation of a test packet between a session sender and a session reflector when using a protocol such as TWAMP. FIG. 6 is a time chart showing Example 1 of the operation when a test packet is transmitted in accordance with the provisions of IETF RFC4656, Sections 3.5 and 3.6. FIG. 7 is a time chart showing Example 2 of the operation when a test packet is transmitted in accordance with the provisions of IETF RFC4656, Sections 3.5 and 3.6. FIG. 8 is a block diagram showing three examples of the operation of a communication system. FIG. 9 is a block diagram showing examples of the configuration of a physical machine and a communication system embodying the present invention. FIG. 10 is a flowchart showing Example 1 of the characteristic operation of a physical machine embodying the present invention. FIG. 11 is a schematic diagram showing a specific example of a table used by a physical machine that performs the operation of FIG. 10. FIG. 12 is a flowchart showing a second characteristic operational example of a physical machine that performs the present invention. FIG. 13 is a schematic diagram showing a specific example of a table used by a physical machine that performs the operation of FIG. 12. FIG. 14 is a graph showing three types of RTT change examples. FIG. 15 is a flowchart showing a third characteristic operational example of a physical machine that performs the present invention. FIG. 16 is a schematic diagram showing a specific example of a table used by a physical machine that performs the operation of FIG. 15.

[0030] Embodiments of the present invention will be described below with reference to the drawings. <Outline of Configuration and Operation> Figure 8 shows an example of the configuration and operation of three types of communication systems 500A, 500B, and 500C. Each of the communication systems 500A, 500B, and 500C shown in Figure 8 has three nodes 501, 502, and 503. Furthermore, nodes 501 and 502 are connected via a transmission path 511, and nodes 501 and 503 are connected via a transmission path 512.

[0031] For example, if a common user terminal is connected downstream of node 502 and downstream of node 503 via transmission paths not shown, data can be transmitted from the upstream node 501 to the user terminal via node 502, or data can be transmitted from node 501 to the same user terminal via node 503.

[0032] Therefore, when transmitting data from the node 501 to a common user terminal or the like, if link aggregation is configured across a network switch, it is possible to use either of the two transmission paths 511 and 512. As a typical example, it is assumed that the transmission path 511 is used as a main path (active system) and the transmission path 512 is used as a backup path (standby system), and that in the event of a failure or the like, the active system and the standby system are switched for use.

[0033] Here, it is necessary to measure the network performance between two points on the network. Therefore, in a communication system such as 500A in Fig. 8, a test packet Pt is transmitted in both directions between node 501 and node 502, and further between node 501 and node 503.

[0034] In the example of the communication system 500A shown in Fig. 8, it is assumed that the test packets Pt are transmitted by the general method shown in Fig. 6 or 7. Therefore, in the communication system 500A, the transmission frequency of the test packets Pt passing through the transmission path 511 and the transmission frequency of the test packets Pt passing through the transmission path 512 are approximately equal.

[0035] However, if test packets Pt are sent frequently with priority given to anomaly detection, the software processing of the node increases. In particular, if anomaly detection on the backup route is delayed or not possible in a redundant configuration such as LAG, there is a risk of communication interruption after route switching in the event of a failure on the main route. However, the above problem cannot be solved regardless of whether the control shown in Figure 6 or Figure 7 is performed.

[0036] Therefore, in the embodiment of the present invention, the transmission frequency of the test packets Pt is dynamically controlled according to the situation, thereby realizing a more appropriate communication environment. Specifically, the transmission frequency of the test packets Pt is controlled in the same manner as the operation of the communication systems 500B and 500C shown in FIG.

[0037] 8 uses a transmission path 511 connecting a node 501 and a node 502 as a main path (active system), and a transmission path 512 connecting a node 501 and a node 503 as a backup path (standby system). In addition, the transmission frequency of test packets Pt on the transmission path 511, which is the main path, is controlled to be lower than the transmission frequency of test packets Pt on the transmission path 512, which is the backup path.

[0038] As a result, the frequency of transmission of test packets Pt on the main path is low, which reduces the processing load associated with network performance measurement of the active system and improves the processing performance of the active system other than network performance measurement. Also, the frequency of transmission of test packets Pt on the backup path is high, which improves the network performance measurement function of the standby system, improves availability after switching between the active system and the standby system, and enables early detection of failures.

[0039] In the communication system 500B in FIG. 8, the transmission frequency of the test packets Pt in the active system is normally reduced from the standard value, and the transmission frequency of the test packets Pt in the standby system is normally increased from the standard value.

[0040] In addition, in the communication system 500B shown in Fig. 8, when a change in the round-trip time (RTT) that differs from normal times is detected in the active system, the standby system increases the transmission frequency of test packets Pt more than usual. This facilitates early detection of faults in the standby system. Moreover, because only the standby system increases the transmission frequency of test packets Pt, an increase in the processing load on the active system can be avoided.

[0041] 8, when a routing switchover occurs, the transmission path 512 is switched from the standby system to the active system, and the transmission path 511 is switched from the active system to the standby system. Here, in order to prioritize the routing process in the active system after the switchover, the transmission frequency of the test packet Pt on the transmission path 512, which is the standby system before the switchover, is reduced in advance from the normal frequency.

[0042] 8 can be housed in a single physical machine. In such a configuration, data communication is assumed to be performed between a first physical machine housing node 501 and a second physical machine housing multiple nodes 502 and 503, for example, via a predetermined gateway router. In this case, multiple transmission paths 511 and 512 can be switched between active and standby systems for communication.

[0043] <Configuration Example of a Communication System> Fig. 9 shows a configuration example of a physical machine and a communication system embodying the present invention. For example, the physical machine 10A shown in Fig. 9 includes the function of the "communication control device" of the present invention. In the example shown in Fig. 9, one physical machine 10A and another physical machine 10B are connected to each other via a communication network 300. Therefore, data communication can be performed between two points: a node on the physical machine 10A side and a node on the adjacent physical machine 10B side.

[0044] The physical machine 10A shown in Figure 9 includes multiple m physical interfaces 11-1, 11-2, ..., 11-m, communication buses 13 and 14, a transmit packet processor 15, a receive packet processor 16, memory 17, a container engine 18, a virtualized container 19, and a host OS (operating system) 20. The physical machine 10B in Figure 9 also includes the same components as the physical machine 10A. Note that interfaces are abbreviated as "IF" in the drawings.

[0045] Each of the physical interfaces 11-1 to 11-m is an independent physical NIC (Network Interface Card), and can provide a physical function for communication using the communication network 300. Furthermore, the physical machine 10A can virtually allocate multiple n logical interfaces 12-1, 12-2, ..., 12-n to each of the physical interfaces 11-1 to 11-m. Furthermore, the physical machine 10A can bundle the multiple physical interfaces 11-1 to 11-m and use them as a single virtual NIC.

[0046] This allows the use of link aggregation technology, which means that when communication is performed between the physical machines 10A and 10B in FIG. 9 via the communication network 300, multiple links can be used simultaneously or selectively.

[0047] 9, for example, the links of the multiple transmission paths 511 and 512 shown in FIG. 8 can be used simultaneously, and the link of the transmission path 511 can be assigned to the active system and the link of the transmission path 512 can be assigned to the standby system, or the active system and the standby system can be switched. Also, in order to measure the network performance between each two points of the multiple links, a test packet Pt can be transferred for each link as shown in FIG. 8.

[0048] The transmission packet processing unit 15 in the physical machine 10A processes transmission packets, and the reception packet processing unit 16 processes reception packets. When the physical machine 10A executes the TWAMP protocol, the transmission packet processing unit 15 and the reception packet processing unit 16 can be used as the session sender 102 and the session reflector 202 shown in FIG. 1 .

[0049] The container engine 18 has a function of virtualizing OS resources for each container that serves as a development and execution environment for a virtualized application, and executing, operating, and managing the container by making it appear as an independent OS. Specifically, it has a function of defining a slot schedule value for calculating the test packet transmission period required for OWAMP and TWAMP specified in RFC, defining a "normal RTT value," recording "measured RTT values," and calculating the RTT standard deviation.

[0050] As shown in FIG. 9, the container engine 18 includes a normal RTT definition unit 18a, a transfer unit 18b, an RTT actual measurement value recording unit 18c, an insertion unit 18d, a slot schedule definition unit 18e, a session management unit 18f, an RTT standard deviation recording unit 18g, an RTT standard deviation calculation unit 18h, and a routing table recording unit 18i.

[0051] The virtualization container 19 is a virtualized independent space in which an application environment, such as the main body and configuration files, is constructed. Specifically, it has the function of generating and transmitting test packets and recording the test packet transmission time, which is necessary for calculating the RTT.

[0052] 9, the virtualization container 19 includes a generation unit 19a, an initialization unit 19b, a transmission unit 19c, an analysis unit 19d, a time recording unit 19e, and a parameter acquisition unit 19f. The host OS 20 is constructed by running software using an existing network OS. The control unit 21 in the host OS 20 has a function that allows multiple OSs to be used like applications. Specifically, it has a function to control the processing of received packets and transmitted packets.

[0053] <Description of Characteristic Control> -<Control Example 1> The characteristic operation of "Control Example 1" in a physical machine that embodies the present invention is shown in Fig. 10. Also, a specific example of a table used by a physical machine that performs the operation of Fig. 10 is shown in Fig. 11.

[0054] The data of the normal time RTT definition table TB11, the RTT actual measurement value recording table TB12, and the slot schedule management table TB13 shown in Figure 11 are stored in the normal time RTT definition section 18a, the RTT actual measurement value recording section 18c, and the slot schedule definition section 18e of the container engine 18, respectively.

[0055] The normal RTT definition table TB11 stores constant data for normal RTT (delay time) determined based on the results of prior measurement. In the example shown in Fig. 11, the normal RTT definition table TB11 stores different constant data for each of the IDs of multiple physical interfaces and each of the IDs of multiple logical interfaces. The IDs of LAGs are also stored in the normal RTT definition table TB11.

[0056] The RTT actual measurement value record table TB12 holds RTT data representing the results of actual measurements. In the example shown in Fig. 11, the actual RTT measurement value is held for each measurement date and time, along with the physical interface ID, logical interface ID, and LAG ID. The data held in the RTT actual measurement value record table TB12 is updated each time the RTT is measured.

[0057] The slot schedule management table TB13 holds multiple sets of constant data, each of which includes a schedule name, number of slots, parameter [ms], and type. In the example of the slot schedule management table TB13 shown in Fig. 11, different numbers of slots and parameter constants are registered for the slot schedule "Schedule1" of type "1" and the slot schedule "Schedule2" of type "0." The slot numbers, parameters, etc. in the slot schedule management table TB13 are appropriate constants calculated based on past actual RTT measurements, etc.

[0058] The characteristic operations of the physical machine 10A shown in Figure 10 are described below. In step S11, the physical machine 10A acquires LAG-IDs representing specific links of the physical interfaces 11-1 to 11-m and logical interfaces 12-1 to 12-n to be controlled from the normal RTT definition table TB11. Specifically, this process is performed by the parameter acquisition unit 19f of the virtualization container 19.

[0059] In step S12, the physical machine 10A acquires the parameters of the schedule "Schedule 1" used when transmitting test packets at the normal frequency from the slot schedule management table TB13. Specifically, this process is performed by the parameter acquisition unit 19f of the virtualization container 19.

[0060] In step S13, the physical machine 10A assigns the specific physical interface 11 and the specific logical interface 12 associated with the LAG-ID of the link to the interface of the main path (active system) and establishes a communication session for transferring test packets of the active system. Specifically, the analysis unit 19d of the virtualization container 19 determines the ID of the logical interface of the active system, and under the control of the container engine 18, the transmission packet processing unit 15 processes the test packets, and the reception packet processing unit 16 processes the reception packets.

[0061] In step S14, the physical machine 10A obtains the ID of the logical interface 12 with the smallest number other than the interface already assigned to the active system for the LAG-ID of the link from the normal RTT definition table TB11, and assigns it as the interface of the backup path (standby system). Specifically, the container engine 18 extracts the logical interface ID from the normal RTT definition unit 18a, and the analysis unit 19d of the virtualization container 19 determines the interface of the standby system from the logical interface ID.

[0062] In step S15, the physical machine 10A acquires the parameters of the schedule "Schedule 2" used for transmitting test packets at a relatively high frequency from the slot schedule management table TB13. Specifically, the parameter acquisition unit 19f of the virtualized container 19 acquires the parameters from the slot schedule definition unit 18e of the container engine 18.

[0063] In step S16, the physical machine 10A establishes a communication session for transferring test packets of the standby system using the standby system interface assigned in step S14 and the parameters acquired in step S15. Specifically, the analysis unit 19d of the virtualization container 19 determines the logical interface ID of the standby system interface, and under the control of the container engine 18, the transmit packet processing unit 15 processes the test packets, and the receive packet processing unit 16 processes the receive packets.

[0064] In step S17, the physical machine 10A specifies the acquired parameters in the request session packet from the previous step and transmits it. Specifically, the transmission packet processing unit 15 assigns the parameters acquired by the parameter acquisition unit 19f of the virtualization container 19 to the request session packet, and then transmits the request session packet.

[0065] 10 is performed using the tables shown in Fig. 11, when the physical machine 10A transmits test packets, the transmission frequencies of the active system and the standby system can be determined individually by the parameters of the low-frequency schedule "Schedule 1" and the high-frequency schedule "Schedule 2." Therefore, for example, as in the communication system 500B shown in Fig. 8, the transmission frequency of the test packet Pt of the active system can be reduced and the transmission frequency of the standby system can be increased.

[0066] -<Control Example 2> Figure 12 shows the characteristic operation of "Control Example 2" in a physical machine that implements the present invention. Figure 13 shows a specific example of a table used by a physical machine that implements the operation of Figure 12. Figure 14 shows graphs of three types of RTT change examples.

[0067] The normal time RTT definition table TB21, the RTT actual measurement value recording table TB22, the slot schedule management table TB23, and the RTT standard deviation management table TB24 shown in Figure 13 are stored in the normal time RTT definition section 18a, the RTT actual measurement value recording section 18c, the slot schedule definition section 18e, and the RTT standard deviation recording section 18g of the container engine 18, respectively.

[0068] The contents of the normal time RTT definition table TB21, the actual RTT value recording table TB22, and the slot schedule management table TB23 in Fig. 13 are the same as those of the tables in Fig. 11. The RTT standard deviation management table TB24 shown in Fig. 13 holds the actual RTT value standard deviation and its increment at each time point calculated by the RTT standard deviation calculation unit 18h based on multiple actual RTT values, together with information on the date and time of the last actual RTT measurement.

[0069] 14. The actual RTT measurement value in the communication environment of the physical machine 10A can be expected to undergo three typical RTT change examples G21, G22, and G23. For example, in the first RTT change example G21, the variation (standard deviation) of the actual RTT measurement value is relatively small, and the actual RTT measurement value is below the threshold on average. In other words, the communication delay time (RTT: Round Trip Time) is relatively small, so RTT change example G21 corresponds to a situation in which communication quality is good.

[0070] In the second RTT change example G22, the variation in the actual RTT values ​​is relatively small, and the actual RTT values ​​exceed the threshold on average. In other words, the communication delay time is relatively large, so the RTT change example G22 corresponds to a situation where communication quality is poor. In the third RTT change example G23, the actual RTT values ​​are below the threshold on average, but the variation in the actual RTT values ​​is relatively large. Therefore, the RTT change example G23 corresponds to a situation where communication quality is poor.

[0071] 12. In step S21, the physical machine 10A acquires the actual RTT values ​​of the target interface for the most recent period T (a fixed length) from the actual RTT value recording table TB22. Specifically, the RTT standard deviation calculation unit 18h of the container engine 18 acquires the actual RTT values ​​from the RTT standard deviation recording unit 18g.

[0072] In step S22, the physical machine 10A calculates the average RTT (communication delay time) of the target interface for the most recent period T based on the multiple actual RTT measurements acquired in step S21. That is, the result is obtained by dividing the sum of the actual RTT measurements acquired for the period T by the number of data. Specifically, the RTT standard deviation calculation unit 18h performs this calculation.

[0073] In step S23, the physical machine 10A obtains the normal RTT (communication delay time) of the target interface from the normal RTT definition table TB21. Specifically, the analysis unit 19d of the virtualized container 19 obtains the normal RTT from the normal RTT definition unit 18a of the container engine 18. At the same time, the analysis unit 19d of the virtualized container 19 obtains the average RTT (communication delay time) calculated in the previous step.

[0074] In step S24, the physical machine 10A compares the average RTT (communication delay time) acquired in step S22 with the normal RTT (communication delay time) acquired in step S23 for the target interface. If the average RTT (communication delay time) is greater than the normal RTT (communication delay time), the process proceeds to step S29; if this condition is not met, the process proceeds to step S25. Specifically, the analysis unit 19d of the virtualization container 19 performs this determination.

[0075] In step S25, the physical machine 10A calculates the deviation (difference) from the average RTT (communication delay time) for each of the acquired actual RTT values. Specifically, this calculation is performed by the RTT standard deviation calculation unit 18h of the container engine 18.

[0076] In step S26, the physical machine 10A derives the variance for all the acquired actual RTT values. That is, the physical machine 10A calculates the variance by dividing the sum of the squares of the deviations of the actual RTT values ​​by the number of acquired RTTs. Specifically, the RTT standard deviation calculation unit 18h of the container engine 18 performs this calculation.

[0077] In step S27, the physical machine 10A calculates the standard deviation for all the acquired RTT actual measurement values. That is, it calculates the square root of the variance calculated in step S26. Specifically, the RTT standard deviation calculation unit 18h of the container engine 18 performs this calculation.

[0078] In step S28, the physical machine 10A determines whether the variance acquired in step S26 has increased a predetermined number of times (N times) in succession. That is, in step S28, it determines whether the RTT (communication delay time) fluctuates significantly and the communication state is unstable. If this condition is met, the process proceeds to step S29; if the condition is not met, the process returns to step S21. Specifically, the analysis unit 19d of the virtualization container 19 performs this determination.

[0079] In step S29, the physical machine 10A acquires the parameters of the schedule “Schedule 2” used when transmitting test packets at a high frequency from the slot schedule management table TB23. Specifically, the parameter acquisition unit 19f of the virtualized container 19 acquires the parameters from the slot schedule definition unit 18e of the container engine 18.

[0080] In step S30, the physical machine 10A transmits a stop session packet through the standby interface to terminate the test session. Specifically, the analysis unit 19d of the virtualization container 19 determines the logical interface ID of the standby interface, and the transmission packet processing unit 15 transmits the stop session packet.

[0081] In step S31, the physical machine 10A establishes a new test session using the standby interface. Specifically, the analysis unit 19d of the virtualization container 19 determines the logical interface ID of the standby interface, and the transmission packet processing unit 15 transmits a new request session packet under the control of the container engine 18.

[0082] In step S32, the physical machine 10A specifies the acquired parameters in the request session packet from the previous step and transmits the request session packet. Specifically, the transmission packet processing unit 15 assigns the parameters acquired by the parameter acquisition unit 19f of the virtualization container 19 to the request session packet, and transmits the request session packet.

[0083] In other words, when the physical machine 10A performs the operation shown in Fig. 12, if a change in RTT (communication delay time) that differs from normal times occurs in the active system, this is detected in step S24, and the processing from step S29 onwards is executed. As a result, the frequency of test packet transmission in the standby system increases. Also, if the variation in RTT (communication delay time) increases, for example, as in the RTT change example G23 in Fig. 14, this is detected in step S28, and the processing from step S29 onwards is executed. As a result, the frequency of test packet transmission in the standby system increases.

[0084] 12, the process may be changed to use a moving average of actual RTT (communication delay time) measurements instead of the average RTT (communication delay time). The transmission interval of the test packets is dynamically changed according to the increase in the standard deviation of the RTT (communication delay time) of the active route.

[0085] -<Control Example 3> Characteristic operations of "Control Example 3" in a physical machine embodying the present invention are shown in Fig. 15. Also, a specific example of a table used by a physical machine that performs the operations of Fig. 15 is shown in Fig. 16.

[0086] The routing table TB31 and the slot schedule management table TB32 shown in FIG. 16 are held in the routing table recording unit 18i and the slot schedule definition unit 18e of the container engine 18, respectively.

[0087] 16 holds data on the item number, physical interface ID, route, next hop, and cost value for each of a plurality of route items. Also, the slot schedule management table TB32 holds data on the schedule name, number of slots, parameter [ms], and type for each of a plurality of schedule items.

[0088] The characteristic operation of the physical machine 10A shown in Fig. 15 will be described below. The physical machine 10A performs the operation shown in Fig. 15 when a routing switch occurs. In step S41, the physical machine 10A acquires information about each route of the active system and the standby system based on the contents of the routing table TB31. First, the physical interface ID associated with the LAG is searched for in the routing table TB31, and the cost value of the interface of each route is determined from the contents of the routing table TB31.

[0089] In step S42, the physical machine 10A identifies whether the target interface is a standby path. Specifically, the analysis unit 19d of the virtualization container 19 considers the interface with the lower cost value acquired in step S31 to be the active path interface, and the interface with the higher cost value to be the standby path interface, of the two active and standby paths associated with the same LAG. Then, the process proceeds to step S43 and subsequent steps only when processing the standby path.

[0090] In step S43, the physical machine 10A acquires the parameters of the schedule "Schedule 3," which is prepared for transmitting test packets at a low frequency, from the slot schedule management table TB32. Specifically, the parameter acquisition unit 19f of the virtualized container 19 acquires the parameters of the low-frequency schedule "Schedule 3" from the slot schedule definition unit 18e of the container engine 18.

[0091] In step S44, the physical machine 10A transmits a stop session packet using the interface of the standby path to terminate the test session. Specifically, based on the result of the determination by the analysis unit 19d of the virtualization container 19, the transmission packet processing unit 15 transmits the stop session packet using the interface of the standby path.

[0092] In step S45, the physical machine 10A establishes a new test session using the interface of the standby path. Specifically, based on the result of the determination by the analysis unit 19d of the virtualization container 19, the transmission packet processing unit 15 transmits a request session packet using the interface of the standby path.

[0093] In step S46, the physical machine 10A specifies the acquired parameters in the request session packet from the previous step and transmits the request session packet. Specifically, the transmission packet processing unit 15 assigns the parameters acquired by the parameter acquisition unit 19f of the virtualization container 19 to the request session packet and transmits the request session packet via the interface of the standby path.

[0094] 15 in advance when switching routing, the physical machine 10A can reduce the frequency of test packet transmissions on the standby route before switching. For example, when switching the standby slot schedule from "Schedule 1" to "Schedule 3" using the slot schedule management table TB32 shown in FIG. 16, the parameter changes from "60000 [ms]" to "90000 [ms]" and the type also changes, so the frequency of test packet transmissions on the standby route decreases.

[0095] For example, when the communication system 500C shown in Fig. 8 uses the transmission paths 511 and 512 as the active system and the standby system, respectively, and executes the process shown in Fig. 15 during routing switching, the transmission frequency of the test packet Pt on the transmission path 512, which is the standby system before the path switching, is reduced. Therefore, the routing process on the transmission path 512, which becomes the new active system after the path switching, can be given priority over the processing of the test packet. In other words, by reducing the transmission frequency of the test packet Pt in the standby system before the path switching, the load on the standby system (the active system after the switching) for the process is reduced, and the routing process accompanying the path switching can be executed more smoothly.

[0096] <Features of the Communication Control Device> The following are characteristic features of the communication control device of the present invention: [1] A communication control device (physical machine 10A) that can be used for data communication between two nodes, a first node and a second node, that are connected via a communication network, comprising: a communication unit (physical interfaces 11-1 to 11-m) that corresponds to a redundant communication path including a main path (active system) and a backup path (standby system), a test packet transmission unit (transmission packet processing unit 15) that transmits and receives predetermined test packets in order to measure network performance in both directions between the two points, and a transmission interval control unit (virtualization container 19) that dynamically changes the transmission intervals of the test packets on the main path and the backup path, wherein the transmission interval control unit controls the transmission frequency of the test packets on at least the main path to be lower than the transmission frequency of the test packets on the backup path (S11 to S17).

[0097] According to the communication control device having the configuration [1] above, it is possible to increase the frequency of test packet transmission on the backup route while keeping the frequency of test packet transmission on the main route low. In other words, by maintaining the frequency of test packet transmission on the main route low, it is possible to reduce the load that test packets place on the processing of the main route and the network resources consumed by transmitting test packets. Furthermore, by increasing the frequency of test packet transmission on the backup route, it is possible to detect the occurrence of a failure on the backup route early. Furthermore, it is possible to improve availability after route switching.

[0098] [2] The communication control device according to [1] above, wherein the transmission interval control unit has a schedule management table (slot schedule management table TB13) that separately holds a first constant that affects the transmission frequency of the test packets on the main path and a second constant that affects the transmission frequency of the test packets on the backup path.

[0099] According to the communication control device having the configuration [2] above, the appropriate frequency of sending test packets can be determined for each of the main path and the backup path using a predetermined constant, thereby reducing the processing load associated with sending test packets.

[0100] [3] The communication control device according to [1] above, wherein the transmission interval control unit increases only the transmission frequency of the test packets on the backup path when detecting a change that is different from normal in the RTT determined by the test packets on the main path (S21 to S32).

[0101] The communication control device having the configuration of [3] above facilitates the establishment of a stable communication path. Specifically, when the average RTT on the main path increases or when the RTT variance becomes large, the communication quality of the main path deteriorates, and it is expected that the path used for normal communication will be switched from the main path to a backup path. In this case, by increasing only the frequency of test packet transmission on the backup path, it becomes possible to detect a failure on the backup path early, thereby improving availability after the path switching.

[0102] [4] The communication control device according to [1] above, wherein the transmission interval control unit temporarily reduces the frequency of transmission of the test packets on the backup route compared to normal times when a routing switchover is expected (S41 to S46).

[0103] According to the communication control device having the configuration described in [4] above, for example, immediately before switching the route used for normal communication from the main route to the backup route, the frequency of transmission of the test packets on the backup route is reduced. Therefore, the load imposed by the test packets on the processing of the backup route and the network resources consumed in transmitting the test packets can be reduced. This reduces the processing load and the network resources consumed, increasing the capacity to execute other processes such as routing, and enabling smoother route switching operations.

[0104] 10A, 10B Physical machines 11, 11-1, 11-2, 11-m Physical interfaces 12, 12-1, 12-2, 12-n Logical interfaces 13, 14 Communication bus 15 Transmission packet processing unit 16 Reception packet processing unit 17 Memory 18 Container engine 18a Normal RTT definition unit 18b Transfer unit 18c RTT actual measurement value recording unit 18d Insertion unit 18e Slot schedule definition unit 18f Session management unit 18g RTT standard deviation recording unit 18h RTT standard deviation calculation unit 18i Routing table recording unit 19 Virtualized container 19a Generation unit 19b Initialization unit 19c Transmission unit 19d Analysis unit 19e Time recording unit 19f Parameter acquisition unit 20 Host OS 21 Control unit 100 Device A 101 Control client 110 Physical machine 120 Communication interface 121, 122 Physical NIC 102 Session sender 200 Device B 201 Server 202 Session reflector 210 Network switch 300, 310, 320 Communication network 401, 402 MLAG peer 403 MLAG client 500A, 500B, 500C Communication system 501, 502, 503 Node 511, 512 Transmission path G21, G22, G23 RTT change example P01, P11, P0n, P1n Test packet Pt, Pt1, Pt2, Pt3, Ptm Test packet SL1, SL2, SL3, SLn Time slot T01, T02 Test packet transmission interval Ts, Tx1, Tx2, Tx3, Txm Time interval TB11, TB21 Normal RTT definition table TB12, TB22 RTT actual measurement value record table TB13, TB23, TB32 Slot schedule management table TB24 RTT standard deviation management table TB31 Routing table t0 Start time X1, X2 Failure< / timestamp>

Claims

1. A communication control device that can be used for data communication between two points, a first node and a second node, connected via a communication network, comprising: a communication unit that corresponds to a redundant communication path including a main path and a backup path; a test packet transmission unit that transmits and receives specified test packets in order to measure network performance in both directions between the two points; and a transmission interval control unit that dynamically changes the transmission interval of the test packets on the main path and the backup path, wherein the transmission interval control unit controls at least the transmission frequency of the test packets on the main path to be lower than the transmission frequency of the test packets on the backup path.

2. The communication control device according to claim 1, wherein the transmission interval control unit has a schedule management table that separately holds a first constant that affects the transmission frequency of the test packets on the main path and a second constant that affects the transmission frequency of the test packets on the backup path.

3. The communication control device according to claim 1, wherein the transmission interval control unit increases only the transmission frequency of the test packets on the backup route when it detects a change in the RTT delay time grasped by the test packets on the main route that differs from normal times.

4. The communication control device according to claim 1, wherein the transmission interval control unit temporarily reduces the frequency of transmission of the test packets on the backup route compared to normal operation when a routing switchover is expected to occur.