A frame multi-board card device software upgrading method and system

Abstract

The present application relates to the technical field of device management, and provides a frame multi-board device software upgrading method and system. A first board sends a multicast message of a synchronization software request, and an in-frame switch forwards the multicast message to an in-frame master and other boards and other in-frame switches after receiving the multicast message. The master confirms whether a resource package of a board type carried in the synchronization software request has been distributed historically after receiving the multicast message. If the master has distributed the resource package, the master confirms whether a count value of a receiving counter exceeds a preset threshold value. If the count value does not exceed the preset threshold value, the master directly takes a non-response operation. Otherwise, the master executes distribution. If the master has not distributed the resource package, the master generates a distribution message carrying a resource package according to a first board ID and a board type carried in the synchronization software request. The present application can make all boards serve as servers according to a specified strategy during whole machine upgrading of a frame multi-board device, and shortens the upgrading time.

Description

Technical Field

[0001] This invention relates to the field of equipment management technology, and in particular to a method and system for upgrading software in a frame-type multi-board device. Background Technology

[0002] Upgrades to communication equipment operating on the network are carried out in a planned manner. Equipment software upgrades need to be completed within a specified time and require stable operation of the equipment during the upgrade process. To meet these requirements, equipment software upgrade technology is developing towards improving stability, reliability, miniaturizing packet size, reducing upgrade time consumption, and thus improving upgrade efficiency.

[0003] Cascading multi-board devices to form network elements, such as Figure 1 As shown, a communication device can be understood as a network element. However, with the increasing number of boards in communication devices, the main control unit has become a bottleneck for upgrades. Furthermore, the main control unit's long-term processing of upgrade tasks can affect service processing, especially the processing of sudden service flows.

[0004] When upgrading chassis-type multi-board devices, the main controller acts as the sole server, resulting in long upgrade times and failing to meet the requirements of existing network upgrades. Therefore, overcoming the shortcomings of this existing technology is a pressing issue in this field. Summary of the Invention

[0005] The technical problem this invention aims to solve is that when upgrading a multi-board chassis device, the main controller acts as the sole server, resulting in a long upgrade time and failing to meet the upgrade requirements of the existing network.

[0006] The present invention adopts the following technical solution:

[0007] In a first aspect, the present invention provides a software upgrade method for a chassis-based multi-board device. The system includes one or more chassis, each containing a main controller, boards, and an internal switch. The internal switch is used to facilitate communication between the main controller and boards within the chassis, between boards, and between chassis. The method includes:

[0008] The first board sends a multicast message requesting synchronization software. After receiving the multicast message, the switch in the chassis forwards the multicast message to the main controller and other boards in the chassis, as well as to other switches in the chassis.

[0009] After receiving the multicast message, the master controller confirms whether the resource package of the board type carried in the synchronization software request has been distributed in the past.

[0010] If the master controller has already distributed the resource package, it checks whether the count value of the receiving counter exceeds the preset threshold. If the count value does not exceed the preset threshold, it directly takes no response operation; otherwise, it performs distribution. During the period when the master controller does not respond, the boards that have previously acquired the resource package will generate a distribution message after receiving the multicast message by combining the local previously acquired resource package with the first board ID, and complete the distribution through the switch in the frame.

[0011] If the master controller has not distributed the resource package, it generates a distribution message carrying the resource package based on the first board ID and board type carried in the synchronization software request, and completes the distribution through the switch in the frame.

[0012] Preferably, the boards that have historically acquired the resource package include boards belonging to the same chassis as the first board, as well as boards in other chassis within the system. The method further includes:

[0013] When multicast messages are forwarded between chassis, the switch within the chassis will carry the first chassis ID in the forwarded multicast message;

[0014] If the corresponding returned distribution message comes from another chassis, the distribution message will carry both the first chassis ID and its own second chassis ID, which will be used as the destination field and source field of the chassis in the distribution message, respectively.

[0015] Preferably, the method further includes:

[0016] After receiving the first distribution message, the first board confirms whether the distribution message comes from its own chassis based on the source field of the chassis carried in the distribution message.

[0017] If it is confirmed that the distribution message comes from its own chassis, a receiving channel is established directly and the resource package is downloaded.

[0018] If it is confirmed that the distribution message is from an adjacent chassis, then wait for the receive timer; if the receive timer expires and no distribution message is received from the chassis where it is located, then establish a receive channel with the main control unit or board in the adjacent chassis and complete the download of the resource package; if the distribution message from the chassis where it is located is received before the receive timer expires, then ignore the previously received distribution message from the adjacent chassis, establish a receive channel with the board in its own chassis, and complete the download of the resource package.

[0019] Preferably, before the boards in each chassis receive the corresponding update notification message that can send a synchronization software request, the method further includes:

[0020] The resource packages required by the synchronization software of the boards contained in each chassis in the system are sent centrally to the first master controller in the master chassis. The master controllers in other slave chassis do not send the resource packages in advance.

[0021] Preferably, the method further includes:

[0022] When the second master controller, acting as a slave chassis, receives the multicast message requesting synchronization software for the first time and confirms that there is no corresponding resource package on its local machine, it obtains the list of resource packages from the first master controller, acting as the master chassis, through multicast messages or directed messages.

[0023] As the master controller of a slave chassis, it sends one or more multicast messages for synchronization software requests based on the types of boards and resource package lists within its chassis. When a board in each chassis receives a multicast message for synchronization software requests from the master controller, it responds with a higher priority than when it receives a multicast message for synchronization software requests from the master controller board.

[0024] Preferably, as the second master controller in the slave chassis, upon receiving a second multicast message requesting synchronization from other software, the method further includes:

[0025] As the second master controller of the slave chassis, it confirms whether the required resource packets in the second multicast message have been stored locally;

[0026] If the required resource package is already stored locally, a determination is made as to whether it has been distributed in the past. If the second master control has distributed it, it is confirmed whether the count value of the receiving counter exceeds the preset threshold. If the count value does not exceed the preset threshold, no response is taken directly; otherwise, distribution is performed. If the second master control has not distributed it, a distribution message carrying the resource package is generated based on the board ID and board type carried in the second multicast message, and the distribution is completed through the switch in the frame.

[0027] If the required resource package is not stored locally, no response will be given. The second multicast message will also be forwarded to the boards and master controllers in each box in the system through the box switch and other box switches in the system, so that the boards with the corresponding resource packages can respond.

[0028] Preferably, the first master controller of the host chassis, after receiving the resource package required by the synchronization software of the boards contained in each chassis in the system, sends a multicast message to the system to start the synchronization software update.

[0029] Preferably, as the first master controller of the host rack, after receiving the resource packages required by the synchronization software of the boards contained in each rack in the system, it sends a multicast message to the master controllers of other slave racks in the system to download the complete resource packages. The method further includes:

[0030] Once the master controller in each slave chassis confirms that it has successfully downloaded the complete resource package, it sends a success response message to the first master controller in the master chassis.

[0031] As the primary controller in the host chassis, after confirming that the primary controllers in each slave chassis have completed downloading the complete resource package, it sends a multicast message to all boards in the system to begin synchronizing software updates.

[0032] Preferably, sending the multicast message to all boards in the system to begin synchronizing the software update specifically includes:

[0033] Send a multicast message request to the master controller in all slave chassis within the system to start synchronous software updates;

[0034] Upon receiving the multicast message request to initiate software update synchronization, the master controller in each slave chassis sends the multicast message to initiate software update synchronization within its own chassis.

[0035] Secondly, the present invention also provides a chassis-type multi-board device software upgrade system, the system including a host chassis and one or more slave chassis, each chassis containing a main controller, boards, and an in-chassis switch, wherein the in-chassis switch is used to complete message communication between the main controller and boards within the chassis, between boards, and between chassis, the system comprising:

[0036] The first board in the host chassis sends a multicast message requesting synchronization software. After receiving the multicast message, the switch in the host chassis forwards the multicast message to the first master controller and other boards in the chassis, as well as the switches in other slave chassis.

[0037] After receiving the multicast message, the first master controller confirms whether the resource package of the board type carried in the synchronization software request has been distributed in the past.

[0038] If the first master control has already distributed the resource package, it is confirmed whether the count value of the receiving counter exceeds the preset threshold. If the count value does not exceed the preset threshold, the operation of not responding is directly adopted; otherwise, the distribution is performed. During the period when the first master control does not respond, the boards that have previously acquired the resource package will generate a distribution message by combining the local previously acquired resource package with the first board ID after receiving the multicast message, and complete the distribution through the switch in the frame.

[0039] If the first master controller has not distributed the resource package, a distribution message carrying the resource package is generated based on the first board ID and board type carried in the synchronization software request, and the distribution is completed through the switch in the frame.

[0040] This invention enables all boards to act as servers during the overall upgrade of a multi-board chassis device according to a specified strategy, allowing for parallel distribution and processing of software packages and shortening the upgrade time.

[0041] The software package distribution efficiency is improved, and the upgrade time is shortened. In single-frame scenarios, the device upgrade time can be effectively reduced. In extended-frame scenarios, multiple frames are connected out-of-band, and the number of boards to be upgraded increases exponentially. The solution of this invention will greatly shorten the upgrade time and improve the reliability of device operation during the upgrade. The main controller has more computing resources for the management and control planes during the whole machine upgrade than before the solution was implemented. Attached Figure Description

[0042] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly described below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0043] Figure 1 This invention provides a frame-type multi-board device software package structure in the prior art.

[0044] Figure 2 This is a resource pack storage format on a motherboard card provided in an embodiment of the present invention;

[0045] Figure 3 This is a signaling timing diagram in the prior art provided by the present invention, in which the main controller acts as a single entity for upgrade processing;

[0046] Figure 4 This is a flowchart of a software upgrade method for a frame-type multi-board device provided by an embodiment of the present invention;

[0047] Figure 5 This is a flowchart illustrating the detailed process of a software upgrade method for a frame-type multi-board device provided in an embodiment of the present invention.

[0048] Figure 6 This is a flowchart of the main control side software upgrade for a frame-type multi-board device provided in an embodiment of the present invention;

[0049] Figure 7 This is a flowchart of a software upgrade method for a chassis-type multi-board device provided by an embodiment of the present invention, from the chassis main control side.

[0050] Figure 8 This is a flowchart of a software upgrade method for a chassis-type multi-board device provided by an embodiment of the present invention, broken down from the chassis main control side.

[0051] Figure 9This is a schematic diagram of a frame-type multi-board device software upgrade system architecture provided by an embodiment of the present invention;

[0052] Figure 10 This is a priority flow diagram of a software upgrade system for a chassis-type multi-board device provided in an embodiment of the present invention;

[0053] Figure 11 This is a schematic diagram of the structure of a software upgrade package for a frame-type multi-board device provided in an embodiment of the present invention. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0055] In the description of this invention, the terms "inner", "outer", "longitudinal", "lateral", "upper", "lower", "top", "bottom", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and do not require that this invention must be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting this invention.

[0056] In this invention, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0057] In this application, unless otherwise expressly specified and limited, the term "connection" should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral part; it can be a direct connection or an indirect connection through an intermediate medium. Furthermore, the term "coupled" can refer to an electrical connection that enables signal transmission.

[0058] Before describing specific embodiments, this invention first analyzes aspects of reducing upgrade time consumption and ensuring the reliability of the upgrade process, as follows:

[0059] The software package structure of the chassis-type multi-board device involved is as follows: Figure 2 As shown, the main controller will obtain the entire small package file and will split the small package file according to the types of boards it maintains and manages, such as... Figure 2As shown, the resource table for board type 1 describes the need for small packets 1, 2, and 6, while the resource table for board type 2 describes small packets 1, 2, and 9. In actual implementation, there can be one or more board entities for board type 1. For the main controller, it needs to parse this description file in advance, repackage the small packets into larger packets, and then forward them to the corresponding board entities under the board type (e.g., ...). Figure 1 (One or more of the boards 1-16 in the chassis). Software upgrades for chassis-type multi-board devices require... Figure 1 The main controller distributes packets to each board within the device. Packet distribution is a CPU-intensive and network-resource-intensive task. To ensure that the main controller can handle business operations during the upgrade, only one request can be processed at a time. Figure 3 As shown, in the first processing cycle of the main controller, although upgrade requests were received from board 1, board 2, and board n, however, as Figure 3 The dashed line indicates that the corresponding main controller only responded to the request from board 1 in the first processing cycle, as shown below. Figure 3 In the first processing cycle, the completion message indicates that the upgrade request is for board 1. However, in the second processing cycle, since board 1's request has already been responded to and completed, no further upgrade requests for board 1 are received. Instead, upgrade requests for boards 2 and n are received (this is because the upgrade requests for boards 2 and n were rejected or ignored in the first processing cycle, and therefore they will re-initiate upgrade requests to the main controller after a preset interval). However, in the second processing cycle, the main controller will still only select board 2 to respond to and complete its upgrade process. Figure 3 As can be seen, the upgrade request for board n is responded to and completed in the third processing cycle. It should be noted that the order in which the main controller responds to the upgrade request can be arranged according to the order in which the upgrade request messages are received, or according to the importance level of the corresponding boards, or even according to a more sophisticated upgrade strategy (proposed by this invention). These will not be elaborated upon here, but will be described in detail during the implementation of the specific scheme. The upgrade processing time is directly proportional to the number of boards; as the number of boards increases, the upgrade time becomes longer.

[0060] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0061] Example 1:

[0062] Embodiment 1 of the present invention provides a software upgrade method for a chassis-type multi-board device, such as... Figure 1As shown, the system includes one or more chassis, each containing a main controller, circuit boards, and an internal switch. The internal switch is used for communication between the main controller and circuit boards within the chassis, between circuit boards, and between different chassis. Figure 1 In Chinese, a communication device is simply a chassis entity; the two are different expressions of the same concept. Figure 4 As shown, the method includes:

[0063] In step 201, the first board sends a multicast message requesting synchronization software. After receiving the multicast message, the switch in the chassis forwards the multicast message to the main controller and other boards in the chassis, as well as to other switches in the chassis.

[0064] The multicast message is broadcast within the system as a group. The multicast message does not specify a destination address, but is forwarded by the switch within the frame to all cards in the system.

[0065] In step 202, after receiving the multicast message, the master controller confirms whether the resource package of the board type carried in the synchronization software request has been distributed in the past.

[0066] like Figure 2 As shown, the resource package of the board type here is represented in the instance scenario, that is... Figure 2 In the resource description of board type 1, "small package 1", "small package 2" and "small package 6" are the resource packages of board type 1; while in the resource description of board type 2, "small package 1", "small package 2" and "small package 9" are the resource packages of board type 2.

[0067] This means that, before receiving the multicast message of the synchronization software request from the first board, the master controller may have already responded to synchronization software requests from other boards of the same type as the first board. If the master controller has already responded, the corresponding resource packet sending action will be recorded, thus completing the corresponding analysis in step 202. This brings out the core idea of ​​the present invention: if the master controller confirms that the resource packet has been distributed in the past, it can simply assume that, without any faults or changes, there should be a board that can directly provide the resource packet request in the multicast message, and then step 203 can be executed.

[0068] In step 203, if the master controller has already distributed the data, it is confirmed whether the count value of the receiving counter exceeds the preset threshold. If the count value does not exceed the preset threshold, no response is taken directly; otherwise, distribution is performed.

[0069] During the period when the master controller does not respond, the boards that have previously acquired the resource package will, upon receiving the multicast message, generate a distribution message by combining the local boards that have previously acquired the resource package with the first board ID, and complete the distribution through the switch within the frame.

[0070] The lack of response here provides a time window and opportunity for other boards that have previously acquired the corresponding resource package to act as servers and respond to the multicast message. Therefore, the preset threshold considers that boards that have previously acquired the resource package may malfunction, experience computational congestion, or be unloaded. Thus, once the count exceeds the preset threshold, the controller determines that one of these situations has occurred and must distribute the resource package itself, thereby executing the corresponding distribution process. The specific distribution process can be found in step 204, and will not be elaborated upon here.

[0071] In step 204, if the master controller has not distributed the resource package, a distribution message carrying the resource package is generated based on the first board ID and board type carried in the synchronization software request, and the distribution is completed through the switch in the frame.

[0072] This invention, in its embodiments, ensures that all boards in a multi-board chassis can function as servers during system upgrades using a specified strategy. This enables parallel distribution of software packages, shortening upgrade time. Improved package distribution efficiency and reduced upgrade time are achieved, effectively reducing upgrade time in single-chassis scenarios. In expanded chassis scenarios, multiple chassis connect out-of-band, doubling the number of boards to be upgraded. This invention significantly reduces upgrade time and improves equipment reliability during upgrades. Furthermore, the main controller has more computing resources available for management and control planes during system upgrades compared to before implementation.

[0073] In this embodiment of the invention, the boards that have historically acquired the resource package include boards belonging to the same chassis as the first board, as well as boards in other chassis within the system. The implementation method is usually as follows: when multicast messages are forwarded between chassis, the switch within the chassis will carry the first chassis ID in the forwarded multicast message; if the corresponding returned distribution message comes from other chassis, the distribution message will carry both the first chassis ID and its own second chassis ID, which will be used as the destination field and source field content of the chassis in the distribution message, respectively.

[0074] Based on the above implementation, in this embodiment of the invention, the first board executes the method integrity upon receiving the first distribution message, such as... Figure 5 As shown, step 301 follows step 204 of the present invention, and the corresponding method further includes:

[0075] In step 301, after receiving the first distribution message, the first board confirms whether the distribution message comes from its own chassis based on the source field of the chassis carried in the distribution message.

[0076] In step 302, if it is confirmed that the distribution message comes from its own chassis, a receiving channel is directly established and the resource package is downloaded.

[0077] In step 303, if it is confirmed that the distribution message is from an adjacent chassis, then wait for the receive timer.

[0078] The reason for performing the receive timer operation here is to compensate for the latency caused by potential delays in response from local boards. From a system perspective, allowing boards within the same chassis to act as servers for resource packet distribution is preferable to cross-chassis distribution. This is not only to simplify network data packet transmission redundancy but also because boards within the same chassis transmit subsequent data more efficiently only through their own chassis switches.

[0079] In step 304, if the receiving timer expires and the distribution message of its own chassis is not received, a receiving channel is established with the main control or board in the adjacent chassis, and the resource package is downloaded.

[0080] Steps 304 and 305 analyze two scenarios regarding the received timer results. In step 304, no distribution message is received from the local chassis, meaning the local chassis has previously acquired resource packages of the same type of board. This could be due to reasons such as system crashes, power outages, system freezes, or removal, preventing feedback within the acceptable time frame. Therefore, for the sake of overall system upgrade efficiency, using distribution messages from boards in adjacent chassis is more appropriate. In step 304 above, it was also mentioned that the corresponding distribution message could also originate from the master controller in an adjacent chassis. This situation is more likely to occur when the master controller of the host chassis has already pre-distributed the total resource package to each slave chassis before the board obtains the ability to start sending the synchronization software request. If the other mode proposed in this invention is adopted, that is, the master controller of the slave chassis and the motherboard of the slave chassis start from the same point, and both start after the master controller of the host chassis sends the start command, then the master controller in the slave chassis also needs to complete the acquisition of its own local resource package. Moreover, the master controller in the slave chassis will also choose to refuse the response operation if the historical distribution record is confirmed, just like the master controller in the host chassis. This will be described in detail later.

[0081] In step 305, if a distribution message from its own chassis is received before the receiving timer expires, the previously received distribution messages from adjacent chassis are ignored, a receiving channel with the boards in its own chassis is established, and the resource package is downloaded.

[0082] The extended explanation of step 304 above has already outlined at least two modes for establishing the resource package of the master controller in the chassis. The following example will elaborate on how the master controller in the master chassis and the master controller in the slave chassis complete the establishment of the original resource package. Specifically, before the boards in each chassis receive the corresponding update notification message that allows them to send a synchronization software request, the method further includes:

[0083] The resource packages required by the synchronization software of the boards contained in each chassis in the system are sent centrally to the first master controller in the master chassis. The master controllers in other slave chassis do not send the resource packages in advance.

[0084] What is meant here is that, in this embodiment of the invention, at the start of the upgrade activity (i.e., the process carrying the synchronization software request described in this embodiment), only the main controller has a complete resource package. At this time, only the main controller of the host chassis can act as the server for distributing resource packages. The goal of the upgrade is to recombine the resource packages into smaller packages according to the board type (e.g., ...). Figure 2 (As shown) Distributed to each board in the host chassis, and to each board in the extension chassis present in the system.

[0085] like Figure 6 As shown, the main controller of the host chassis will receive a synchronization software request from the board. The main controller of the host chassis will not immediately reply to the board, but will instead... Figure 6 The strategy execution in the process includes:

[0086] 1. This type of resource package has never been distributed before, indicating that only the host frame's main controller has it; proceed with the distribution.

[0087] 2. "Already distributed" indicates that the resource package has been deployed to other boards. These other boards can act as servers to provide download services. Distribution is only provided when the same request (i.e., the board ID in the request indicates that all requests originate from the same board) is received n times consecutively. Here, 'n' can be reasonably set based on the actual average response latency of the boards and the retransmission frequency of the multicast messages for the corresponding synchronization software requests. This value is stored in the `Node.req` field in the program pseudocode. The principle is that during the n-1 time periods when the master controller of the host chassis refuses distribution, other boards have the opportunity to become servers. This strategy effectively distributes the package resources to other boards first, and then these boards that have already downloaded the package resources act as servers to jointly provide download services to the other boards.

[0088] In this embodiment of the invention, the board may be taken offline. At this time, the information that the main controller has synchronized will be cleared. If the main controller receives a synchronization request from other similar boards, it will process it as if the packet has not been distributed, that is, reply immediately. This ensures the integrity and reliability of the whole machine packet distribution.

[0089] After introducing how to create resource packages for the main controller in the host chassis, we can directly use... Figure 6 The flowchart below provides a supplementary explanation of the principle mechanism of this invention embodiment. Next, a method will be provided for how to initially establish the resource package for the second master controller in the slave chassis, such as... Figure 7 As shown, the method also includes:

[0090] In step 401, when the second master controller, acting as a slave chassis, receives the multicast message requesting the synchronization software for the first time and confirms that there is no corresponding resource package on its local machine, it obtains the resource package list from the first master controller, acting as the master chassis, through multicast messages or directed messages.

[0091] In step 402, the master controller, acting as a slave chassis, sends one or more multicast messages of synchronization software request based on the types of boards and resource package lists within its chassis.

[0092] When a board in each chassis receives a multicast message requesting synchronization from the master controller's synchronization software, it responds with a higher priority than a multicast message requesting synchronization from the motherboard's synchronization software. Typically, the second master controller in a slave chassis sends multicast messages to the entire chassis to retrieve the types of boards within its chassis.

[0093] From the perspective of the logical integrity of the solution, as the second master controller of the slave chassis, when it receives a second multicast message requesting other synchronization software, such as Figure 8 As shown, the method also includes:

[0094] In step 501, the second master controller, acting as a slave chassis, confirms whether the required resource packets are already stored locally based on the second multicast message.

[0095] In step 502, if the required resource package is already stored locally, a determination is made as to whether it has been distributed in the past. Step 503 or 504 is then executed; otherwise, step 505 is executed.

[0096] In step 503, if the second master controller has already distributed the data, then no response is required.

[0097] In step 504, if the second master control has not distributed the data, a distribution message carrying resource packages is generated based on the board ID and board type carried in the second multicast message, and the distribution is completed through the switch within the frame.

[0098] In step 505, if the required resource package is not stored locally, no response is taken.

[0099] The second multicast message will also be forwarded through the in-frame switch and other in-frame switches within the system to the boards and master controllers in each frame contained in the system, so that the boards with the corresponding resource packages can respond.

[0100] One of the main methods for obtaining the complete resource package from the master controller in the slave chassis, as described in this embodiment of the invention, is as follows:

[0101] As the primary controller of the host chassis, after receiving the resource packages required by the synchronization software of the boards contained in each chassis in the system, it sends a multicast message to the system to start the synchronization software update.

[0102] As another method for establishing the acquisition of the complete resource package from the master controller in the slave chassis, which is the main feature of this embodiment of the invention, it will be described in more detail below:

[0103] As the primary controller of the host chassis, after receiving the resource packages required by the synchronization software of the boards contained in each chassis in the system, it sends a multicast message to the primary controllers of other slave chassis in the system to download the complete resource packages. The method also includes:

[0104] Once the master controller in each slave chassis confirms that it has successfully downloaded the complete resource package, it replies with a success response message to the first master controller in the master chassis. After confirming that the master controllers in each slave chassis in the system have completed the download of the complete resource package, the first master controller in the master chassis sends a multicast message to all boards in the system to start synchronizing software updates.

[0105] The biggest difference between the two methods is that the former allows the slave chassis's master controller to participate in the multicast message acquisition of resource packets, just like all the other cards in the system, while the latter divides the operation into two levels: the slave chassis's master controller first receives the complete resource packet from the master controller of the master chassis, and then initiates the multicast message process for the synchronization software requests of all cards at the system level. Both methods have their advantages and disadvantages for this invention. The former is simpler and more efficient when network bandwidth is sufficient; the latter, because it is divided into two stages, wastes bandwidth and card performance resources during the process of the slave chassis's master controller acquiring the complete resource packet.

[0106] In the latter solution described above, the sending of a multicast message to all boards in the system to initiate software update synchronization specifically includes:

[0107] The master controller in each slave chassis sends a multicast message request to start synchronizing software updates to all slave chassis. Upon receiving the multicast message request, the master controller in each slave chassis sends a multicast message to start synchronizing software updates within its own chassis.

[0108] Example 2:

[0109] This invention also provides a software upgrade system for a chassis-type multi-board device, such as... Figure 9 As shown, here Figure 9 The example shown is the former mode of the two methods described in Embodiment 1, in which the master controller of the slave chassis participates in the acquisition of its own resource packages synchronously with each board in the system. However, this does not mean that the system in this embodiment is only applicable to this mode, but should be understood as such. Figure 9 This is merely one scenario that can be used to implement the system in this embodiment. As another mode in Embodiment 1, the system in this embodiment is also applicable, and should not be considered as such. Figure 9 The system diagram imposes too many restrictions on the scope of protection of this embodiment.

[0110] The system in this embodiment includes a master chassis and one or more slave chassis. Each chassis houses a master controller, circuit boards, and an internal switch. The internal switch is used to facilitate communication between the master controller and circuit boards within the chassis, between circuit boards, and between chassis. The system includes:

[0111] The first board in the host chassis sends a multicast message requesting synchronization software. After receiving the multicast message, the switch in the host chassis forwards the multicast message to the first master controller and other boards in the host chassis, as well as the switches in other slave chassis.

[0112] After receiving the multicast message, the first master controller confirms whether the resource package of the board type carried in the synchronization software request has been distributed in the past.

[0113] If the first master control has already distributed the resource package, it is confirmed whether the count value of the receiving counter exceeds the preset threshold. If the count value does not exceed the preset threshold, the operation of not responding is directly adopted; otherwise, the distribution is performed. During the period when the first master control does not respond, the boards that have previously acquired the resource package will generate a distribution message by combining the local previously acquired resource package with the first board ID after receiving the multicast message, and complete the distribution through the switch in the frame.

[0114] If the first master controller has not distributed the resource package, a distribution message carrying the resource package is generated based on the first board ID and board type carried in the synchronization software request, and the distribution is completed through the switch in the frame.

[0115] exist Figure 9 In this context, pkg-1, pkg-2, ..., pkg-n are the corresponding... Figure 2 The terms "packet 1", "packet 2", ..., "packet n" are equivalent representations of each other. In the board, the dashed box representing "pkg" indicates that the corresponding board has not yet acquired its meaning, while the corresponding dashed arrow indicates the sending direction of the packet. The dashed arrow is merely a logical link; the actual signal transmission still depends on... Figure 9 The solid lines in the diagram represent the physical links used to complete this process.

[0116] This invention, in its embodiments, ensures that all boards in a multi-board chassis can function as servers during system upgrades using a specified strategy. This enables parallel distribution of software packages, shortening upgrade time. Improved package distribution efficiency and reduced upgrade time are achieved, effectively reducing upgrade time in single-chassis scenarios. In expanded chassis scenarios, multiple chassis connect out-of-band, doubling the number of boards to be upgraded. This invention significantly reduces upgrade time and improves equipment reliability during upgrades. Furthermore, the main controller has more computing resources available for management and control planes during system upgrades compared to before implementation.

[0117] After the upgrade activity begins, the boards to be upgraded will send out software synchronization requests and select a server to download package resources according to the strategy. For example... Figure 10 As shown, in the following description, the main controller and board in Embodiments 1 and 2 are uniformly and simplified as nodes:

[0118] After sending the synchronization request, wait for a reply;

[0119] If no node responds after the timeout period, the synchronization software request is sent again.

[0120] If a node responds after the timeout period, the number of responding nodes should be checked. If only one node responds, that node should be selected for downloading the package resources. If more than one node responds, a priority selection strategy should be used, as described below:

[0121] 1) Chassis IDs with the same frame ID have higher priority than chassis IDs with different frame IDs;

[0122] 2) The main control board has a higher priority than other types of boards;

[0123] 3) Nodes with lower current load have higher priority; in this case, the corresponding response message will also include a description of the node's load status.

[0124] like Figure 11 As shown, the board downloads package resources in segments, controlling the segmentation process through protocol interaction with the server. The segment size is configurable, ensuring each segment is written to memory instead of caching the entire package. 3) Nodes with lower current loads have higher priority; the corresponding response message will also include a description of the node's load. This effectively controls memory usage during package download. Segmented packet transmission also enables resume functionality. When a service node goes offline, the board requests package resources from other service nodes and incrementally transmits segments based on already transmitted segments, avoiding duplicate transmissions of existing segments.

[0125] It is worth noting that the information interaction and execution process between the modules and units in the above-mentioned device and system are based on the same concept as the processing method embodiment of the present invention. For details, please refer to the description in the method embodiment of the present invention, and will not be repeated here.

[0126] Those skilled in the art will understand that all or part of the steps in the various methods of the embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc.

[0127] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A software upgrade method for a chassis-type multi-board device, characterized in that, The system includes one or more chassis, each containing a main controller, circuit boards, and an internal switch. The internal switch facilitates communication between the main controller and circuit boards within the chassis, between circuit boards, and between chassis. The method includes: The first board sends a multicast message requesting synchronization software. After receiving the multicast message, the switch in the chassis forwards the multicast message to the main controller and other boards in the chassis, as well as to other switches in the chassis. After receiving the multicast message, the master controller confirms whether the resource package of the board type carried in the synchronization software request has been distributed in the past. If the master controller has already distributed the resource package, it checks whether the count value of the receiving counter exceeds a preset threshold. If the count value does not exceed the preset threshold, it directly takes no response operation; otherwise, it performs distribution. During the period when the master controller does not respond, the boards that have previously acquired the resource package will generate a distribution message after receiving the multicast message, based on the local historical acquisition of the resource package and the first board ID, and complete the distribution through the switch in the frame. If the master controller has not distributed the resource package, it generates a distribution message carrying the resource package based on the first board ID and board type carried in the synchronization software request, and completes the distribution through the switch in the frame.

2. The software upgrade method for a frame-type multi-board device according to claim 1, characterized in that, The boards that have historically acquired the resource package include boards belonging to the same chassis as the first board, as well as boards in other chassis within the system. The method further includes: When multicast messages are forwarded between chassis, the switch within the chassis will carry the first chassis ID in the forwarded multicast message; If the corresponding returned distribution message comes from another chassis, the distribution message will carry both the first chassis ID and its own second chassis ID, which will be used as the destination field and source field of the chassis in the distribution message, respectively.

3. The software upgrade method for a frame-type multi-board device according to claim 2, characterized in that, The method further includes: After receiving the first distribution message, the first board confirms whether the distribution message comes from its own chassis based on the source field of the chassis carried in the distribution message. If it is confirmed that the distribution message comes from its own chassis, a receiving channel is established directly and the resource package is downloaded. If it is confirmed that the distribution message is from an adjacent chassis, then wait for the receive timer; if the receive timer expires and no distribution message is received from the chassis where it is located, then establish a receive channel with the main control unit or board in the adjacent chassis and complete the download of the resource package; if the distribution message from the chassis where it is located is received before the receive timer expires, then ignore the previously received distribution message from the adjacent chassis, establish a receive channel with the board in its own chassis, and complete the download of the resource package.

4. The software upgrade method for a frame-type multi-board device according to any one of claims 1-3, characterized in that, Before the boards in each chassis receive the corresponding update request multicast message to send a synchronization software request, the method further includes: The resource packages required by the synchronization software of the boards contained in each chassis in the system are sent centrally to the first master controller in the master chassis. The master controllers in other slave chassis do not send the resource packages in advance.

5. The software upgrade method for a frame-type multi-board device according to claim 4, characterized in that, The method also includes: When the second master controller, acting as a slave chassis, receives the multicast message requesting synchronization software for the first time and confirms that there is no corresponding resource package on its local machine, it obtains the list of resource packages from the first master controller, acting as the master chassis, through multicast messages or directed messages. As the master controller of a slave chassis, it sends one or more multicast messages of synchronization software request based on the types of boards and resource package lists within its chassis. When a board in each chassis receives a multicast message of synchronization software request from the master controller, it responds with a higher priority than when it receives a multicast message of synchronization software request from the master controller.

6. The software upgrade method for a frame-type multi-board device according to claim 5, characterized in that, As the second master controller in the slave chassis, when it receives a second multicast message from other synchronization software, the method also includes: As the second master controller of the slave chassis, it confirms whether the required resource packets are already stored locally based on the second multicast message; If the required resource package is already stored locally, a determination is made as to whether it has been distributed in the past. If the second master control has distributed it, it is confirmed whether the count value of the receiving counter exceeds the preset threshold. If the count value does not exceed the preset threshold, no response is taken directly; otherwise, distribution is performed. If the second master control has not distributed it, a distribution message carrying the resource package is generated based on the board ID and board type carried in the second multicast message, and the distribution is completed through the switch in the frame. If the required resource package is not stored locally, no response will be given. The second multicast message will also be forwarded to the boards and master controllers in each box in the system through the box switch and other box switches in the system, so that the boards with the corresponding resource packages can respond.

7. The software upgrade method for a frame-type multi-board device according to claim 6, characterized in that, As the primary controller of the host chassis, after receiving the resource packages required by the synchronization software of the boards contained in each chassis in the system, it sends a multicast message to the system to start the synchronization software update.

8. The software upgrade method for a frame-type multi-board device according to claim 4, characterized in that, As the primary controller of the main rack, after receiving the resource packages required by the synchronization software of the boards contained in each rack in the system, it sends a multicast message to the primary controllers in other slave racks in the system to download the complete resource packages. The method also includes: Once the master controller in each slave chassis confirms that it has successfully downloaded the complete resource package, it sends a success response message to the first master controller in the master chassis. As the primary controller in the host chassis, after confirming that the primary controllers in each slave chassis have completed downloading the complete resource package, it sends a multicast message to all boards in the system to begin synchronizing software updates.

9. The software upgrade method for a frame-type multi-board device according to claim 8, characterized in that, The sending of a multicast message to all boards in the system to begin synchronizing software updates specifically includes: Send a multicast message request to the master controller in all slave chassis within the system to start synchronous software updates; Upon receiving the multicast message request to initiate software update synchronization, the master controller in each slave chassis sends the multicast message to initiate software update synchronization within its own chassis.

10. A software upgrade system for a chassis-type multi-board device, characterized in that, The system includes a master chassis and one or more slave chassis. Each chassis houses a master controller, circuit boards, and an internal switch. The internal switch is used for communication between the master controller and circuit boards within the chassis, between circuit boards, and between chassis. The system includes: The first board in the host chassis sends a multicast message requesting synchronization software. After receiving the multicast message, the switch in the host chassis forwards the multicast message to the first master controller and other boards in the chassis, as well as the switches in other slave chassis. After receiving the multicast message, the first master controller confirms whether the resource package of the board type carried in the synchronization software request has been distributed in the past. If the first master controller has already distributed the resource package, it checks whether the count value of the receiving counter exceeds a preset threshold. If the count value does not exceed the preset threshold, it directly takes no response operation; otherwise, it performs distribution. During the period when the first master controller does not respond, the boards that have previously acquired the resource package will generate a distribution message after receiving the multicast message, based on the local historical acquisition of the resource package and the first board ID, and complete the distribution through the switch in the frame. If the first master controller has not distributed the resource package, a distribution message carrying the resource package is generated based on the first board ID and board type carried in the synchronization software request, and the distribution is completed through the switch in the frame.

Images