Communication device and start-up method
The communication device optimizes network state management to prevent service interruptions by determining consistent states before restarting control units, ensuring continuous packet forwarding.
Patent Information
- Application Number
- PCT/JP2024/020815
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-06-07
- Publication Date
- 2025-12-11
AI Technical Summary
Existing virtualization technologies face inefficiencies in resource utilization and service interruptions when functional units controlling interfaces or ASICs are restarted in communication devices, particularly in environments where state updates are frequent.
A communication device with a forwarding unit and control container that determines consistent network states before initiating initialization control, allowing packet forwarding to continue without interruptions, and a monitoring container to manage planned and unplanned restarts.
The device ensures continuous packet forwarding and prevents service interruptions by optimizing initialization control based on consistent network states, even during unplanned restarts.
Smart Images

Figure JP2024020815_11122025_PF_FP_ABST
Abstract
Description
Communication device and startup method
[0001] The present invention relates to a communication device and a startup method.
[0002] Virtualization technology has been proposed to run multiple applications on a single physical computer. A VM (Virtual Machine) is a technology that provides a virtual computer dedicated to an application as an execution environment including a guest OS (Operating System) for running the application.
[0003] However, since a VM that provides a separate guest OS for each application requires a large amount of capacity to build a single VM, using multiple applications simultaneously on a single computer can result in a decrease in the resource efficiency of the physical computer.
[0004] On the other hand, a virtualization technology has also been proposed in which applications share a common OS, but each application is provided with its own configuration file for the execution environment in which it runs, and the application and execution environment are integrated as a "container." Non-Patent Document 1 proposes a container runtime as a software platform for running containers. Non-Patent Document 2 proposes container orchestration, which is used to increase the availability of containers through automatic recovery.
[0005] docker, "Docker Builds: Now Lightning Fast," [online], [Retrieved May 20, 2024], Internet <URL: https: / / www.docker.com / > kubernetes, "Production-Grade Container Orchestration," [online], [Retrieved May 20, 2024], Internet <URL: https: / / kubernetes.io / >
[0006] White-box switches, which are general-purpose bare-metal switches equipped with ASICs (Application Specific Integrated Circuits) that perform packet forwarding processing, are attracting attention. The advent of white-box switches has made it possible to separate hardware and software, which is expected to reduce procurement costs and improve the flexibility of network construction. One approach to implementing a Network Operating System (NOS) that controls white-box switches is to build a container application equipped with ASIC control functions.
[0007] FIG. 7 is an explanatory diagram showing the restart process of a control container 15z accompanied by an interface down. State 310, state 320, and state 330 are all snapshots showing state changes for the same computer, the communication device 1z. The communication device 1z has a forwarding unit 12z and interfaces (IFs 11Lz and 11Rz) as a data plane. The forwarding unit 12z is implemented by a DSP (Digital Signal Processor) that performs L1 packet control and an ASIC that performs L2 / L3 packet control. The IFs 11Lz and 11Rz are interfaces controlled by the forwarding unit 12z and send and receive packets.
[0008] The communication device 1z has a control container 15z that serves as a control plane and is responsible for updating the network state, such as routing. The control container 15z operates via a container runtime 14z on a host OS 13z, causing the communication device 1z, which is a white-box switch, to operate as a network node. The host OS 13z also stores configuration data for the IFs 11Lz and 11Rz, such as forwarding tables, in non-volatile memory as a configuration 13Cz.
[0009] State 310 indicates a state in which the operation of the control container 15z has stopped due to a crash 311 occurring in the control container 15z. State 320 indicates a state in which, after state 310, the container runtime 14z, upon detecting the stop of the control container 15z, notifies the control container 15z of a start command 321. State 330 indicates a state in which, after state 320, the control container 15z has restarted. In this state, the control container 15z executes initialization control involving the following two processes (IF initialization process and transfer unit initialization process). - "IF initialization process" (arrow 332) resets the IFs 11Lz and 11Rz. Note that this IF initialization process temporarily transitions the IFs 11L and 11R to a link-down state. - "Transfer unit initialization process" resets the config 13Cz (arrow 331) in the non-volatile memory read from the host OS 13z to the transfer unit 12z after the IF initialization process.
[0010] On the other hand, even if the operation of the control container 15z stops, packet forwarding processing can continue as long as the data plane (forwarder 12z, IFs 11Lz, 11Rz) is operating. In other words, when packet forwarding processing continues normally, there is room for avoiding a drop in the quality of communication services by omitting initialization control from the control plane (IF initialization processing, forwarder initialization processing). Note that conventional technologies such as Non-Patent Documents 1 and 2 do not describe any technology that allows packet forwarding processing to continue as much as possible when the IF control function is stopped unplanned.
[0011] Therefore, a main object of the present invention is to prevent interruption of packet forwarding processing even when a functional unit that controls an IF or ASIC is restarted.
[0012] In order to solve the above problems, the communication device of the present invention comprises the following means: The present invention is a communication device having a forwarding unit that determines an interface to which a packet received by the device itself is to be forwarded based on a set first config, and a control unit that executes initialization control to exchange network states with other devices, reconfigure the interface, and then set a second config in the forwarding unit, thereby causing the interface to temporarily transition to a link-down state, wherein after startup, the control unit executes a process to determine whether to omit the initialization control when the first config set in the forwarding unit and the second config read from a non-volatile storage area are consistent and the network state of the other device and the network state of the device itself are consistent.
[0013] According to the present invention, even if a functional unit that controls an IF or an ASIC is restarted, it is possible to suppress interruptions in packet forwarding processing.
[0014] FIG. 1 is a configuration diagram of a communication device according to the present embodiment; FIG. 2 is a flowchart showing processing executed after a control container according to the present embodiment is restarted; FIG. 3 is an explanatory diagram showing the restart processing of a control container via a monitoring container according to the present embodiment; FIG. 4 is a flowchart showing the planned restart processing of a control container according to the present embodiment; FIG. 5 is a flowchart showing the unexpected restart processing of a control container according to the present embodiment; FIG. 6 is a hardware configuration diagram of a communication device according to the present embodiment; FIG. 7 is an explanatory diagram showing the restart processing of a control container accompanied by an interface down;
[0015] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.
[0016] 1 is a configuration diagram of a communication device 1. State 110 → State 120 are snapshots showing state changes for the communication device 1, which is the same computer. The communication device 1 is, for example, a white-box switch that applies NOS functions to a bare metal switch. The communication device 1 has, as a data plane, a forwarding unit 12 such as a DSP that performs L1 packet control and an ASIC that performs L2 / L3 packet control, and IFs 11L and 11R that are controlled by the forwarding unit 12 and are interfaces that send and receive packets.
[0017] In the host OS 13, HW config (first config) set in the hardware (HW) of the data plane (IFs 11L, 11R, forwarding unit 12), such as a forwarding table, is stored in non-volatile memory as config (second config) 13C. Config 13C is persistent setting data saved in non-volatile memory. Based on the set config 13C, the forwarding unit 12 determines the IFs 11L, 11R to which packets received by the forwarding unit 12 are to be forwarded.
[0018] The communication device 1 has a control plane that uses containers to implement the NOS network control (L2 / L3 control) function and a control container 15 that handles network (NW) state update processing (hereinafter referred to as "state update processing"). Network state refers to configuration data, such as session and routing, that is rewritten in a relatively short time. The control container (control unit) 15 operates via a container runtime 14 on the host OS 13, causing the communication device 1 to operate as a network node equivalent to a router or switch. The control container 15 exchanges network states with adjacent devices (other devices) 21L and 21R to generate its own device configuration 13C. The control container 15 (NOS function) provides functions for controlling hardware using a software development kit (SDK) provided by hardware, including ASICs, which are semiconductor integrated circuits for data transfer control. Some functions, such as ASIC transfer processing, continue to operate even after the NOS is stopped.
[0019] Furthermore, after restarting itself, the control container 15 determines whether initialization control is required, which involves the following two processes (IF initialization process and transfer unit initialization process), and executes the initialization control if required. - "IF initialization process" (arrow 332 in FIG. 7) to reset IFs 11L and 11R. Note that this IF initialization process temporarily transitions IFs 11L and 11R to a link-down state. - "Transfer unit initialization process" to reset the configuration 13C (arrow 121) in the non-volatile memory read from the host OS 13 to the transfer unit 12 after the IF initialization process.
[0020] State 110 indicates a state in which the container runtime 14 has notified the control container 15 of a startup command 111. State 120 indicates a state in which the control container 15 has issued various startup commands after state 110. In this state, the control container 15 reads the configuration 13C stored in non-volatile memory from the host OS 13 (arrow 121). The control container 15 also reads the configuration (hereinafter referred to as HW configuration) set from the data plane (IFs 11L, 11R and the transfer unit 12) (arrow 122).
[0021] Furthermore, after rebooting, the control container 15 acquires the network state (hereinafter referred to as "adjacent state") from the adjacent devices 21L and 21R (arrow 123), and also acquires the network state (hereinafter referred to as "own state") within the network to which the communication device 1 belongs. Note that the own state of the control container 15 disappears after rebooting, but it may be possible to restore the own state from information (such as HW config) remaining in hardware such as the forwarding unit 12. Furthermore, the control container 15 may recalculate the own state by actually sending test traffic.
[0022] If the following (first condition) and (second condition) are both satisfied, the control container 15 may determine that initialization control is not necessary and may decide to omit initialization control (hereinafter referred to as "initialization control omission decision process"). (First condition) The Config 13C and the HW Config have consistent information, such as matching in content. (Second condition) The adjacent state and its own state have consistent information, such as matching in content. This consistency check process is performed using, for example, Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), or Reverse Address Resolution Protocol (ARP). As a result, even if the operation of the control container 15 stops, packet forwarding processing can continue without stopping the data plane, thereby preventing communication service interruptions.
[0023] On the other hand, a case where (the first condition) is not met is, for example, when the HW config is corrupted due to a memory error, etc. Also, a case where (the second condition) is not met is, for example, when the state update process for the adjacent devices 21L and 21R is executed while the control container 15 is stopped, causing only the network states of the adjacent devices 21L and 21R to become up to date. When (the first condition) or (the second condition) is not met, the control container 15 determines that it is necessary to perform initialization control.
[0024] FIG. 2 is a flowchart showing the process executed after the control container 15 is restarted. This flowchart begins after the control container 15 is restarted upon receiving the startup command 111 shown in FIG. 1. The control container 15 acquires the HW configuration from the IFs 11L and 11R and the transfer unit 12 (S11, arrow 122 in FIG. 1). The control container 15 acquires the configuration 13C from the host OS 13 (S12, arrow 121 in FIG. 1). The control container 15 determines whether the configuration in S11 matches the configuration in S12 (S13). If the result in S13 is Yes, the control container 15 acquires the network state (local state) from the communication device 1, which is its own device (S14). The control container 15 acquires the network state (adjacent state) from the adjacent devices 21L and 21R (S15, arrow 123 in FIG. 1). The control container 15 determines whether the network state in S11 matches the network state in S12 (S16). If the answer is No in S13 or No in S16, the control container 15 executes initialization control (S17). On the other hand, if the answer is Yes in S13 and Yes in S16, the control container 15 executes initialization control omission determination processing and ends the processing of FIG. 2.
[0025] As described above, the communication device 1 described in FIGS. 1 and 2 is suitable for situations where state update processing between adjacent devices 21L and 21R is not performed (e.g., when a static route is entered by a command from an administrator). Alternatively, the communication device 1 described in FIGS. 1 and 2 is also suitable for situations where state update processing is infrequent (e.g., when network topology changes are infrequent). On the other hand, in a network environment where state update processing is performed on an ongoing basis using a routing protocol such as BGP or OSFP, the second condition is not satisfied and the network state becomes inconsistent (No in S16) frequently. This occurs because the adjacent devices 21L and 21R detect the termination of KeepAlive with the communication device 1 and update the route. Therefore, FIG. 3 and subsequent figures describe a communication device 1 suitable for a network environment where state update processing is performed on an ongoing basis.
[0026] FIG. 3 is an explanatory diagram showing the restart process of the control container 15 via the monitoring container 16. In addition to the configuration described in FIG. 1, the communication device 1 in FIG. 3 further includes a monitoring container (monitoring unit) 16 that operates via the container runtime 14. The monitoring container 16 is a container that executes a monitoring application that monitors each state of the control container 15 (alive state, down state, and elapsed restart time state). Note that instead of being built within the monitoring container 16, the monitoring application may be implemented on the host OS 13 or container runtime 14 side. State 210, state 220, and state 230 are all snapshots that indicate state changes for the communication device 1, which is the same computer.
[0027] State 210 indicates a state in which the monitoring container 16 suspends the state update process with the adjacent devices 21L and 21R following the restart of the control container 15. The monitoring container 16 detects an event that occurred in the control container 15 (the passage of a planned restart time or a sudden crash 211) via a monitoring signal 212. In this case, the monitoring container 16 sends a state update process suspension command 213 to the adjacent devices 21L and 21R. State 220 indicates a state after state 210 in which the container runtime 14 notifies the control container 15 of a start command 221 (similar to state 120 in FIG. 1 ). State 230 indicates a state after state 220 in which the restart of the control container 15 is completed and the state update process with the adjacent devices 21L and 21R is resumed. The monitoring container 16 detects the completion of the restart of the control container 15 via a monitoring signal 231. The monitoring container 16 then sends a state update process restart command 232 to the adjacent devices 21L and 21R.
[0028] In this way, the monitoring container 16 monitors planned activation triggers for the control container 15. When a planned activation trigger occurs, the monitoring container 16 notifies the adjacent devices 21L and 21R of a request to suspend the state update process that updates the network state, and then activates the control container 15. Furthermore, after the activated control container 15 executes initialization control or initialization control omission determination processing, the monitoring container 16 notifies the adjacent devices 21L and 21R of a request to resume the suspended state update process.
[0029] FIG. 4 is a flowchart showing the planned restart process of the control container 15. The monitoring container 16 determines whether the planned restart time has arrived (S31). If the result in S31 is Yes, the monitoring container 16 sends a request to the adjacent devices 21L and 21R to suspend the state update process (S32, suspend command 213 in FIG. 3). The monitoring container 16 then issues a planned command to stop the control container 15 (S33). The container runtime 14 detects the control container 15 being suspended in S33 and restarts the control container 15 (S34, startup command 111 in FIG. 1). The control container 15 then executes the process after the control container 15 is restarted, as described in FIG. 2 (S35). As a result, if initialization control can be omitted, the initialization control omission determination process is executed. The monitoring container 16 then sends a request to the adjacent devices 21L and 21R to resume the state update process suspended in S32 (S36, resume command 232 in FIG. 3).
[0030] 3 and 4, the communication device 1 sets a suspension period for the state update process of the adjacent devices 21L, 21R by the state update process suspension command 213 and the state update process resume command 232 in conjunction with the planned suspension period of the control container 15. As a result, even in a network environment where state update processes are performed at any time, the initialization control omission determination process is executed by making the NW states match (Yes in S16). Note that the state update process suspension command 213 and resume command 232 may use, for example, a mechanism implemented in a router as NSF (Non Stop Forwarding).
[0031] 5 is a flowchart showing the process of restarting the control container 15 unexpectedly. First, the control container 15 unexpectedly crashes and stops operating (goes down) (S41). The monitoring container 16 detects the stop of the control container 15 (S42; in FIG. 3, the unexpected crash 211 is detected by the monitoring signal 212), and sequentially executes the processes of S32, S34, S35, and S36 in FIG. 4. Note that it is desirable that the frequency (cycle) at which the monitoring container 16 detects the stop of the control container 15, such as N consecutive down states, be greater than the frequency (cycle) at which the control container 15 executes the state update process (performs path exchange).
[0032] When the monitoring container 16 detects that the control container 15 has gone down, it notifies the adjacent devices 21L and 21R of a request to suspend the state update process that updates the network state (S32). The container runtime 14 then restarts the control container 15 upon detecting the control container 15's shutdown (S34). After the control container 15 restarts, it executes the control container restart process shown in FIG. 2 (S35), and the monitoring container 16 then sends a request to the adjacent devices 21L and 21R to resume the state update process that was suspended in S32 (S36).
[0033] In this way, the monitoring container 16 monitors for a sudden shutdown of the control container 15. When a sudden shutdown of the control container 15 occurs, the monitoring container 16 notifies the adjacent devices 21L, 21R of a request to suspend the state update process that updates the network state, and then starts the control container 15. Furthermore, after the started control container 15 executes initialization control or initialization control omission determination processing, the monitoring container 16 notifies the adjacent devices 21L, 21R of a request to resume the suspended state update process.
[0034] FIG. 6 is a hardware configuration diagram of the communication device 1. The communication device 1 is configured as a computer 900 having a CPU 901, a RAM 902, a ROM 903, a HDD 904, a communication I / F 905, an input / output I / F 906, and a media I / F 907. The communication I / F 905 is connected to an external communication device 915. The input / output I / F 906 is connected to an input / output device 916. The media I / F 907 reads and writes data from a recording medium 917. Furthermore, the CPU 901 controls each unit by executing a program (startup program) loaded into the RAM 902. This program (also called an application, or an app for short) can be distributed via a communication line or recorded on a recording medium 917 such as a USB memory.
[0035] [Effect] The communication device 1 of the present invention has a forwarding unit 12 that determines IFs 11L and 11R to which packets received by the device itself will be forwarded based on the set HW config, and a control container 15 that executes initialization control to temporarily transition IFs 11L and 11R to a link-down state by exchanging network states with adjacent devices 21L and 21R and reconfiguring IFs 11L and 11R before setting config 13C in the forwarding unit 12. After startup, the control container 15 executes a process to determine whether to omit initialization control if the HW config set in the forwarding unit 12 is consistent with the config 13C read from the non-volatile storage area and if the network states of the adjacent devices 21L and 21R are consistent with the network state of the device itself.
[0036] As a result, when the control container 15 goes down and can be immediately restored, the communication device 1 can continue data plane forwarding without shutting down the IFs 11L and 11R, thereby preventing service interruption. Therefore, even if the functional units that control the IFs and ASICs are restarted, interruptions to packet forwarding processing can be suppressed.
[0037] The communication device 1 of the present invention further has a monitoring container 16 that monitors planned startup triggers for the control container 15, and when a planned startup trigger occurs, the monitoring container 16 notifies adjacent devices 21L, 21R of a request to suspend the state update process that updates the network state, then starts the control container 15, and after the started control container 15 executes initialization control or a process to determine whether to omit initialization control, it notifies adjacent devices 21L, 21R of a request to resume the suspended state update process.
[0038] As a result, in an environment where state update processing protocols such as OSPF and BGP are used, the communication device 1 can continue data plane forwarding and prevent service interruption even if the control container 15 is stopped for a long period of time.
[0039] The communication device 1 of the present invention further has a monitoring container 16 that monitors for a sudden stop of the control container 15, and when a sudden stop of the control container 15 occurs, the monitoring container 16 notifies adjacent devices 21L, 21R of a request to interrupt the state update process that updates the network state, and then starts the control container 15, and after the started control container 15 executes initialization control or a process to determine whether to omit initialization control, it notifies adjacent devices 21L, 21R of a request to resume the interrupted state update process.
[0040] As a result, the communication device 1 can continue data plane transfer and prevent service interruption even if the control container 15 is stopped for a long period of time due to an unexpected restart such as a crash of the control container 15.
[0041] DESCRIPTION OF SYMBOLS 1 Communication device 11L, 11R IF (interface) 12 Transfer unit 13 Host OS 13C Config (second config) 14 Container runtime 15 Control container (control unit) 16 Monitoring container (monitoring unit) 21L, 21R Adjacent device (other device)
Claims
1. A communications device having a forwarding unit that determines the interface to which packets received by the device itself will be forwarded based on a set first config, and a control unit that executes initialization control to exchange network states with other devices, reconfigure the interface, and then set a second config in the forwarding unit, thereby causing the interface to temporarily transition to a link-down state, wherein after startup, the control unit executes a process to determine whether to omit the initialization control if the first config set in the forwarding unit and the second config read from a non-volatile storage area are consistent, and if the network state of the other device and the network state of the device itself are consistent.
2. The communication device according to claim 1, further comprising a monitoring unit that monitors planned activation triggers for the control unit, and when a planned activation trigger occurs, the monitoring unit notifies the other device of a request to suspend the state update process that updates the network state, and then activates the control unit, and after the activated control unit executes the initialization control or the process of determining whether to omit the initialization control, it notifies the other device of a request to resume the suspended state update process.
3. The communication device according to claim 1, further comprising a monitoring unit that monitors for a sudden shutdown of the control unit, wherein the monitoring unit, when a sudden shutdown of the control unit occurs, notifies the other device of a request to suspend a state update process that updates the network state, and then starts the control unit, and after the started control unit executes the initialization control or the process of determining whether to omit the initialization control, notifies the other device of a request to resume the suspended state update process.
4. A startup method characterized in that a communications device has a forwarding unit and a control unit, the forwarding unit determines an interface to which packets received by the device will be forwarded based on a set first config, the control unit exchanges network states with other devices, reconfigures the interface, and then sets a second config in the forwarding unit to determine whether to perform initialization control to cause the interface to temporarily transition to a link-down state, and if the first config set in the forwarding unit and the second config read from a non-volatile storage area are consistent and the network state of the other device and the network state of the device are consistent, the control unit decides to omit the initialization control.
Citation Information
Patent Citations
White-box switch unified configuration management system and method and network operating system
CN112769602A
SoC system monitoring method, device and equipment based on PCIE network card and medium
CN117370103A
Imaging apparatus
JP2003285504A
Communication system
JP2008278164A