Dynamic message management device, equipment, system, method and storage medium

Through the dynamic message scheduling module, network element adaptation module and data management module of the dynamic message management device, thread groups are dynamically created and managed, which solves the data and management consistency problems caused by the distributed deployment of device-side agents, and realizes centralized management and efficient management of multiple network element devices.

CN114640569BActive Publication Date: 2025-03-25ZTE CORP
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202011480301.0
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2020-12-15
Publication Date
2025-03-25
Estimated Expiration
2040-12-15

AI Technical Summary

Technical Problem

Distributed deployment of device-side agents leads to problems inability to ensure data and management consistency.

Method used

It provides a dynamic message management device, including a dynamic message scheduling module, a network element adaptation module and a data management module, and realizes centralized management of network element devices by dynamically creating and managing thread groups.

Benefits of technology

Centralized management of multiple network element devices is realized, data and management consistency problems caused by distributed deployment are solved, and system management efficiency is improved.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114640569B_ABST
    Figure CN114640569B_ABST
Patent Text Reader

Abstract

The present application relates to the field of communications, and discloses a dynamic message management device, equipment, system, method and storage medium. The dynamic message management device of the present application includes: a dynamic message scheduling module, a network element adaptation module and a data management module. Among them, the dynamic message scheduling module is used to extract the network element information of the network element device that reported the device-side proxy function move-up request from the device-side proxy function move-up request when receiving the device-side proxy function move-up request reported by the network element device, and generate a creation instruction for creating a thread group for the network element device according to the network element information; the network element adaptation module is used to create and start a thread group for managing the network element device according to the creation instruction; the data management module is used to manage the network element information. Based on this device, the proxy side functions deployed separately on each network element device are moved up, so that a device deployed with the device can centrally manage multiple network element devices, thereby ensuring the consistency of data and management.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] Embodiments of the present application relate to the field of communications, and in particular to a dynamic message management device, equipment, system, method and storage medium. Background Art

[0002] At present, when the network element devices on the client side and the control devices on the server side interact with each other in data traffic, they usually use the device-side agent deployed separately in the network element devices to achieve interaction with the two. The device-side agent deployed in each network element device is mainly responsible for the alarm management, configuration management, resource management, master control management, adaptation management and other services between the corresponding network element devices and the control devices. That is, the upstream is responsible for communicating with the control devices on the server side and accepting the instructions of the control devices. The downstream is responsible for communicating with the network element devices and reporting various information on the network element devices to the control devices.

[0003] Although this network architecture can achieve communication between the client's network element devices and the server's management and control devices, as the network scale and data volume continue to grow, this distributed deployment of device-side agent management method cannot centrally manage network element devices, thus leading to the problem of being unable to ensure data and management consistency. Summary of the invention

[0004] The purpose of the embodiments of the present application is to provide a dynamic message management device, equipment, system, method and storage medium, aiming to achieve centralized management of network element devices to solve the technical problem of being unable to ensure data and management consistency due to distributed deployment of device-side agents.

[0005] To solve the above technical problems, an embodiment of the present application provides a dynamic message management device, including: a dynamic message scheduling module, a network element adaptation module and a data management module;

[0006] The dynamic message scheduling module is used to extract the network element information of the network element device that reported the device side proxy function move request from the device side proxy function move request when receiving the device side proxy function move request reported by the network element device, and generate a creation instruction for creating a thread group of the network element device according to the network element information;

[0007] The network element adaptation module is used to create according to the creation instruction and start the thread group for managing the network element device;

[0008] The data management module is used to manage the network element information.

[0009] To achieve the above-mentioned purpose, an embodiment of the present application further provides an SDN control device, comprising: an application service layer, a control service layer in communication connection with the application service layer, a device-side proxy layer in communication connection with the control service layer, and a data forwarding layer in communication connection with the device-side proxy layer;

[0010] Among them, the dynamic message management device as described above is deployed in the device-side proxy layer.

[0011] To achieve the above-mentioned purpose, an embodiment of the present application further provides a dynamic message management system, comprising: the SDN control device as described above; and a plurality of network element devices communicatively connected to the SDN control device.

[0012] To achieve the above object, an embodiment of the present application further provides a dynamic message management method, which is applied to the SDN control device as described above, and the method includes:

[0013] When receiving a device-side proxy function move-up request reported by a network element device, the dynamic message scheduling module extracts network element information of the network element device that reports the device-side proxy function move-up request from the device-side proxy function move-up request, and generates a creation instruction for creating a thread group of the network element device according to the network element information;

[0014] The network element adaptation module is created according to the creation instruction, and starts a thread group for managing the network element device;

[0015] The data management module manages the network element information.

[0016] To achieve the above object, the embodiment of the present application further provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the dynamic message management method described above is implemented.

[0017] The dynamic message management device, equipment, system, method and storage medium proposed in the present application, when the dynamic message scheduling module receives the device side proxy function migration request reported by the network element device, it extracts the network element information of the network element device that reports the request from the device side proxy function request, and generates a creation instruction for creating a thread group of the network element device that reports the device side proxy function request according to the network element information, and finally the network element adaptation module can create according to the creation instruction and start the thread group that manages the network element device that reports the device side proxy function request, thereby realizing the migration of the device side proxy function, that is, there is no need to deploy the device side proxy function separately in each network element device, and when realizing the migration of the device side proxy function, specifically according to the network element information of different network element devices that report the device side proxy function migration request, the thread group for managing each network element device is dynamically created, that is, different network element devices are managed by different thread groups in a device deployed with a dynamic message management device, thereby realizing the centralized management of multiple network element devices by one device, and solving the technical problem that the data and management consistency cannot be guaranteed due to the distributed deployment of the device side agent.

[0018] In addition, in the dynamic message management device, equipment, system, method and storage medium proposed in the present application, since the network element information of each network element device that completes the migration of the device-side proxy function is uniformly managed by the data management module, the device deployed with the dynamic message management device can communicate with each network element device that completes the migration of the device-side proxy function in the future. It can realize accurate identification of the network element devices managed by each thread group based on the network element information managed in the data management module, and then realize communication with each network element device. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] One or more embodiments are exemplarily described by the pictures in the corresponding drawings, and these exemplary descriptions do not constitute limitations on the embodiments.

[0020] Figure 1 It is a structural diagram of a dynamic message management device provided in the first embodiment of the present application;

[0021] Figure 2 It is a structural diagram of a dynamic message management device provided in the second embodiment of the present application;

[0022] Figure 3 It is a structural diagram of the upward movement of the device-side proxy function in the dynamic message management device provided in the second embodiment of the present application;

[0023] Figure 4 It is a structural diagram of an SDN control device provided in the third embodiment of the present application;

[0024] Figure 5It is a structural diagram of a dynamic message management system provided by the fourth embodiment of the present application;

[0025] Figure 6 is a flowchart of a dynamic message management method provided in the fifth embodiment of the present application;

[0026] Figure 7 This is a schematic diagram of the startup timing of the functional modules involved in implementing the upward migration of the device-side agent in the dynamic message management method provided in the fifth embodiment of the present application. DETAILED DESCRIPTION

[0027] To make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the embodiments of the present application will be described in detail below in conjunction with the accompanying drawings. However, it will be appreciated by those skilled in the art that in the present application, many technical details are proposed in order to enable the reader to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical scheme claimed in the present application can also be implemented. The division of the following embodiments is for the convenience of description, and the specific implementation of the present application should not be construed as any limitation, and the various embodiments can be combined and referenced with each other under the premise of no contradiction.

[0028] The first embodiment of the present application relates to a dynamic message management device.

[0029] like Figure 1 As shown, the dynamic message management device 100 includes: a dynamic message scheduling module 10, a network element adaptation module 11 and a data management module 12, and in specific implementation, these three functional modules are interconnected and communicated with each other.

[0030] Among them, the dynamic message scheduling module 10 is used to extract the network element information of the network element device that reported the device-side proxy function move-up request from the device-side proxy function move-up request when receiving the device-side proxy function move-up request reported by the network element device, and generate a creation instruction for creating a thread group for the network element device according to the network element information; the network element adaptation module 11 is used to create and start the thread group that manages the network element device according to the creation instruction; the data management module 12 is used to manage the network element information.

[0031] In addition, in this embodiment, the network element adaptation module 11 specifically includes a unified resource abstraction submodule and a link resource management submodule.

[0032] Correspondingly, when the network element adaptation module 11 creates and starts the thread group for managing the network element device according to the creation instruction provided by the dynamic message scheduling module, the unified resource abstraction sub-module first generates a unified resource abstraction thread according to the creation instruction, so that the unified resource abstraction thread abstracts the resource model corresponding to the network element device to obtain the abstract resource model; then the link management sub-module generates a link management thread according to the creation instruction, so that the link management thread allocates link resources to the abstract resource model and manages the link resources.

[0033] Furthermore, in actual applications, if the dynamic message scheduling module 10 receives device-side proxy function move-up requests reported by multiple network element devices, in order to avoid a large number of creation instructions for creating thread groups that manage different network element devices from piling up in the network element adaptation module 11, thereby causing the network element adaptation module 11 to be paralyzed, an operation queue for adding creation instructions can be created in advance, so that after the dynamic message scheduling module 10 generates corresponding creation instructions based on the network element information of different network element devices, the generated creation instructions can be directly added to the operation queue in sequence, and then the network element adaptation module 11 can take out the creation instructions from the operation queue in a first-in-first-out order, and create and start the thread group that manages the corresponding network element device according to the taken out creation instructions.

[0034] Therefore, in the dynamic message scheduling device provided by the present embodiment, when the dynamic message scheduling module 10 receives the device side proxy function migration request reported by the network element device, it extracts the network element information of the network element device that reports the request from the device side proxy function request, and generates a creation instruction for creating a thread group of the network element device that reports the device side proxy function request according to the network element information, and finally the network element adaptation module 11 can create according to the creation instruction and start the thread group that manages the network element device that reports the device side proxy function request, thereby realizing the migration of the device side proxy function, that is, there is no need to deploy the device side proxy function separately in each network element device, and when realizing the migration of the device side proxy function, specifically according to the network element information of different network element devices that report the device side proxy function migration request, the thread group for managing each network element device is dynamically created, that is, different network element devices are managed by different thread groups in a device deployed with a dynamic message management device, thereby realizing the centralized management of multiple network element devices by one device, and solving the technical problem that the data and management consistency cannot be guaranteed due to the distributed deployment of the device side agent.

[0035] In addition, in this embodiment, since the network element information of each network element device that has completed the migration of the device-side proxy function is uniformly managed by the data management module 12, the device deployed with the dynamic message management device can, when subsequently communicating with each network element device that has completed the migration of the device-side proxy function, realize accurate identification of the network element devices managed by each thread group based on the network element information managed in the data management module 12, and then realize communication with each network element device.

[0036] In addition, it should be noted that the data management module 12 in this embodiment specifically refers to a functional module for managing a database. In practical applications, the data management module 12 can be a database directly.

[0037] That is to say, after the network element adaptation module 11 creates and starts the thread group that manages different network element devices, in order to facilitate the dynamic message management device to subsequently communicate and interact with these network element devices that have completed the migration of the device-side proxy function, the network element information of the network element devices that have completed the migration of the device-side proxy function needs to be synchronously updated to the database, that is, it must be uniformly managed by the data management module 12.

[0038] Furthermore, in this embodiment, the data management module 12 has a relational database that supports scalability, off-site backup, and off-site disaster recovery, thereby enabling management of various data.

[0039] In addition, in actual applications, the length and format of the network element ID (Identity document) of different network element devices vary. Therefore, in order to facilitate management, when the network element information of the network element device with the device-side proxy function is added to the database, a network element number that can identify its uniqueness can be assigned to the network element device according to preset rules.

[0040] Furthermore, a correspondence between the network element number and the network element ID can be established, and then based on the correspondence between the two, the network element ID corresponding to each network element number can be quickly located to locate the network element information of unconnected network element devices.

[0041] In addition, it is worth mentioning that the above-mentioned dynamic message scheduling module 10 is also used to generate a deletion instruction for deleting the thread group that manages the network element device according to the network element information.

[0042] Correspondingly, the network element adaptation module 11 is further configured to delete the thread group managing the network element device according to the deletion instruction.

[0043] It can be seen from the above description that the network element adaptation module 11 includes a unified resource abstraction submodule and a link management submodule.

[0044] Therefore, when the network element adaptation module 11 deletes the thread group that manages the network element device according to the deletion instruction, the unified resource abstraction submodule first deletes the unified resource abstraction thread according to the deletion instruction; then the link resource management submodule deletes the link management thread according to the deletion instruction, and releases the link resources allocated to the abstract resource model.

[0045] Furthermore, in order to ensure that the network element information of the network element devices managed in the data management module 12 remains synchronized with the network element devices managed by the existing thread group, the dynamic message scheduling module 10 is also used to control the data management module 12 to modify the managed network element information and update the managed memory after the network element adaptation module 11 deletes the thread group managing the network element device according to the deletion instruction.

[0046] It should be noted that the above-mentioned control data management module 12 modifies the managed network element information and updates the managed memory. Specifically, it means retaining the network element number assigned to the network element device, but clearing the network element information corresponding to the network element device, that is, releasing the memory previously occupied by the network element device so that the released memory can be allocated to other network element devices for use.

[0047] It is worth mentioning that all modules involved in this embodiment are logic modules. In practical applications, a logic unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. In addition, in order to highlight the innovative part of the present invention, this embodiment does not introduce units that are not closely related to solving the technical problem proposed by the present invention, but this does not mean that there are no other units in this embodiment.

[0048] The second embodiment of the present application relates to a dynamic message management device. In order to solve the communication problem with each network element device under central management after the device-side proxy function is moved up, such as Figure 2 As shown, the dynamic message management device involved in this embodiment is based on the dynamic message management device involved in the first embodiment and is further provided with a resource query adaptation module 13, a configuration management module 14, and an alarm management module 15.

[0049] The dynamic message scheduling module 10 is used to communicate with the resource query adaptation module 13 so that the resource query adaptation module 13 can respond to the resource query of the network element device managed by the thread group. In addition, the dynamic message scheduling module 10 is used to communicate with the configuration management module 14 so that the configuration management module 14 can implement the service configuration of the network element device managed by the thread group.

[0050] In addition, the dynamic message scheduling module 10 is used to communicate with the alarm management module 15 so that the alarm management module 15 can implement alarm management of the network element device managed by the thread group.

[0051] Furthermore, in order to realize the communication problem between the device-side proxy function after the upward movement and the corresponding network element device, the dynamic message management device also includes Figure 2 The remote procedure call module 16 shown in .

[0052] Specifically, the remote procedure call module 16 is respectively communicated with the dynamic message scheduling module 10, the alarm management module 15, the configuration management module 14, and the resource query adaptation module 13, so that the dynamic message management device can realize dynamic message scheduling between the network element devices with the device-side agent function moved up.

[0053] It should be noted that, in this embodiment, the remote procedure call module 16 can be regarded as a gRPCService.

[0054] Accordingly, the remote procedure call module 16 implements the communication between the dynamic message scheduling module 10 and the alarm management module 15 , the configuration management module 14 , and the resource query adaptation module 13 based on the gPRC protocol.

[0055] For ease of understanding, the following describes the process of establishing communication between the dynamic message scheduling module 10 and the alarm management module 15, the configuration management module 14, and the resource query adaptation module 13 by the remote procedure call module 16, as follows:

[0056] First, it should be noted that the dynamic message management device provided in this embodiment needs to be deployed in a corresponding server device in actual application, such as an SDN control device located at the server. Therefore, whether to enable the remote procedure call module 16 is determined by the server registration module in the SDN control device.

[0057] Specifically, the server registration module registers the gRPC service in the SDN control device. If the SDN control device needs to use the gRPC service, the remote procedure call module is started through the server registration module, and then the gRPC service is started.

[0058] Correspondingly, after starting the gRPC service, the server-side listening module deployed in the SDN control device listens to the port pre-agreed with the application (Application, APP) supported by the network element device in the SDN control device, and then receives gRPC information in the port to realize the communication between the dynamic message scheduling module 10 and the alarm management module 15, the configuration management module 14, and the resource query adaptation module 13.

[0059] Thus, the dynamic message management device provided in this embodiment can realize the upward movement of the device-side proxy function located in each network element device, thereby realizing the centralized management of each network element device, and at the same time, based on Figure 2 The structure shown is that the dynamic message management device can also realize communication with the network element device with the function of the upward proxy side device.

[0060] Furthermore, in order to solve the problem that the device-side proxy function cannot communicate with the network element device due to different programming languages ​​after being moved up, the dynamic message management device provided in this embodiment may also include a data structure conversion module, a southbound adaptation communication interface module and a main control management module.

[0061] Among them, the main control management module is respectively communicated with the dynamic message scheduling module, the data structure conversion module and the southbound adaptation communication interface module.

[0062] Since the main control management module is mainly connected to the dynamic message scheduling module, the data structure conversion module and the southbound adaptation communication interface module, for the convenience of explanation, the following is combined Figure 3 The partial structure of the dynamic message management device shown is explained.

[0063] like Figure 3 As shown, the main control management module 19 is respectively communicated with the dynamic message scheduling module 10, the data structure conversion module 17 and the southbound adaptation communication interface module 18, and is used to initialize the dynamic message scheduling module 10, the data structure conversion module 17 and the southbound adaptation communication interface module 18, so that the dynamic message management device can realize the device-side agent migration or dynamic message scheduling between network element devices.

[0064] Correspondingly, the data structure conversion module 17 is used to convert the data of different structures received by the thread group created by the network element adaptation module 11 for managing the network element device into a data structure that can be recognized by the dynamic message scheduling module 10, so that the dynamic message scheduling module 10 distributes the converted data to the corresponding functional modules, such as the resource query adaptation module 13, the configuration management module 14 and the alarm module 15.

[0065] The southbound adaptation communication interface module 18 is used to send the feedback data of each functional module, such as the resource query adaptation module 13, the configuration management module 14 and the alarm module 15, to the network element device managed by the thread group.

[0066] It should be noted that, in this actual application, the data structure conversion module 17 can adopt protobuf (a tool library with efficient protocol data interaction format) provided by Google, so as to be able to identify parameters of different types, such as string type, integer type, floating point type, byte type, Boolean type, etc., or a combination of several of them.

[0067] Accordingly, in order to realize the communication with the network element device after the device-side proxy function is moved up, the remote procedure call module 17 also needs to communicate with the data structure conversion module 17 and the southbound adaptation communication interface module 18, and then when the remote procedure call module 17 completes the request information to gPRC, such as data reporting, query, deletion, etc., the data structure conversion module 17 can convert the parameter information in the received request into the basic type information in the language format of the server, and further convert it into the input parameters of the service interface provided by the server, so as to make a response suitable for the gPRC request information according to the input parameters.

[0068] In addition, it is worth mentioning that the dynamic message scheduling module 10 mentioned above includes but is not limited to being responsible for the device-side agent function, as well as message sending, message receiving, timing processing, communication between threads, creation of thread groups for managing network element devices, and deletion of thread groups for managing network element devices.

[0069] The unified resource abstraction submodule 11-1 includes but is not limited to abstract reporting and processing of various resource models on the device side, namely, network element devices, and converts various modules such as single boards, racks, slots, ports, etc. of the device into more vivid abstract resource models to facilitate the needs of path calculation and business processing.

[0070] The link resource management submodule 11 - 2 includes but is not limited to being responsible for managing various resources of the link, including allocation and release of various resources such as time slots, bandwidths, ports, and network elements.

[0071] The main control management module 19 is responsible for controlling the system startup process. The system startup includes but is not limited to the process in which the relevant modules in the system complete initialization according to the specified process or mechanism, establish a cooperative relationship, and achieve normal processing or realization of a predetermined function.

[0072] It is understandable that system startup is a universal processing flow. In different application scenarios, only the startup modules and steps are slightly different, but the startup strategy and the process control of the steps required for startup are unified. The design of this part needs to consider universality in order to develop a startup plan that can meet different application scenarios.

[0073] The alarm management module 15 includes but is not limited to being responsible for device-side alarm monitoring, alarm query, alarm reporting, alarm synchronization, etc.

[0074] The configuration management module 14 includes but is not limited to realizing the configuration of electrical layer and optical layer services.

[0075] The resource adaptation query module 13 includes but is not limited to adapting the southbound and northbound interfaces. Its processing is command-level processing, that is, different adaptations are performed for each command.

[0076] In addition, for the northbound interface, it is necessary to adapt the structural data models from different northbound sources, including but not limited to OPENFLOW, NETCONF (an XML-based network configuration protocol), CLI (command-line interface), RESTCONF and other protocols to the data structure that can be recognized by the internal data structure, and then send them to the relevant functional modules.

[0077] For the southbound interface, data from functional modules including but not limited to LRM, TAP, ALARM (alarm management), CONFIG (configuration management) etc. needs to be sent to the network element device via including but not limited to gRPC.

[0078] The third embodiment of the present application relates to an SDN management and control device.

[0079] It should be noted that the so-called SDN specifically refers to Software Defined Network, which is an open network architecture with the main features of centralized control and network programmability. In other words, the control equipment based on this network architecture, namely the SDN control equipment mentioned in this embodiment, can allow network administrators to manage and operate the entire network in a software programming manner.

[0080] In addition, since SDN separates the logical control function from the data forwarding function, the network controller of the genetic software implements the logical control function of the network, while the underlying network equipment only needs to be responsible for implementing simple data forwarding functions, interacting with the network controller through protocols such as OpenFlow (a network communication protocol that belongs to the data link layer and can control the forwarding plane of online switches or routers, thereby changing the network path taken by network data packets).

[0081] Based on this, this embodiment deploys the dynamic message management device provided by the first or second embodiment into the SDN control device, thereby realizing the centralized control of multiple network element devices by one SDN control device, and communicating and interacting with each controlled network element device.

[0082] like Figure 4 As shown, the SDN control device 200 provided in this embodiment includes: an application service layer 201, a control service layer 202 communicating with the application service layer 201, a device-side proxy layer 203 communicating with the control service layer 202, and a data forwarding layer 204 communicating with the device-side proxy layer 203.

[0083] In addition, in order to enable the SDN control device 200 to move the existing device-side proxy function located in the network element device to the SDN control device 200, and then the SDN control device 200 centrally manages each network element device, thereby solving the technical problem of being unable to ensure data and management consistency due to distributed deployment, that is, deploying and managing each network element device's device-side proxy separately in each network element device. The dynamic message management device provided in the first or second embodiment is specifically deployed in the device-side proxy layer.

[0084] Furthermore, in actual applications, the application service layer 201 includes, but is not limited to, network management / application program (APP) applications, command line applications, security applications, and other applications.

[0085] Furthermore, in actual applications, the management and control service layer 202 can be further divided into northbound protocol services, core management and control service clusters, and southbound protocol services.

[0086] Among them, the services of the northbound protocol include, but are not limited to, northbound interface, feedback module, conversion module and other functional modules.

[0087] Accordingly, the core managed service cluster includes, but is not limited to, business processing, data model, path processing, data storage, fault management, performance management, configuration management, system management, topology management, security management, resource management, log management, fiber management and other management modules, so that the SDN management and control device 00 can implement the above-mentioned management of each network element device according to business needs when interacting with each network element device.

[0088] Accordingly, the services of the southbound protocol include, but are not limited to, the OpenFlow protocol, the P4 (a high-level language for writing protocol-independent packet processors) protocol, the NETCONF (a new network configuration based on the extensible markup language XML) protocol, the gRPC (a high-performance, open source general remote procedure call RPC framework) protocol and other communication protocols.

[0089] Furthermore, in actual applications, the device-side proxy layer 203 includes, but is not limited to, the functional modules included in the dynamic message management device provided in the first or second embodiment, so that the SDN control device 200 can move the proxy-side functions distributedly deployed in each network element device to the SDN control device 200, thereby realizing centralized management of each network element device.

[0090] Therefore, the SDN control device provided in this embodiment, by integrating the dynamic message management device provided in the first or second embodiment, can dynamically create a thread group to manage each network element device based on the cooperation of each functional module in the dynamic message management device and according to the network element information of different network element devices that report the device-side agent function migration request. That is, different network element devices are managed by different thread groups in a device deployed with a dynamic message management device, thereby realizing centralized management of multiple network element devices by one device, and solving the technical problem of being unable to ensure data and management consistency due to distributed deployment of device-side agents.

[0091] In addition, since the network element information of each network element device that has completed the migration of the device-side proxy function is uniformly managed by the data management module, the SDN control equipment deployed with the dynamic message management device can communicate with each network element device that has completed the migration of the device-side proxy function in the future. It can realize accurate identification of the network element devices managed by each thread group based on the network element information managed in the data management module, and then realize communication with each network element device.

[0092] The fourth embodiment of the present application relates to a dynamic message management system. Figure 5 As shown, the dynamic message management system includes Figure 4 In addition to the SDN control devices shown, there are also several network element devices connected to it, such as Figure 5 Network element device 1, network element device 2...network element device N.

[0093] Among them, the network element device can be any client device that can access the network and communicate with the SDN management and control device, such as a switch, a router, a stand-alone device, etc., which are not listed here one by one, and this embodiment does not impose any restrictions on this.

[0094] Based on this network communication architecture, there is no need to separately deploy the device-side proxy function of each network element device in each network element device. When the network element device communicates and interacts with the SDN control device, it only needs to actively initiate a device-side proxy function migration request to the SDN control device. After receiving the device-side proxy function migration request reported by the network element device, the SDN control device dynamically creates a thread group to manage each network element device based on the network element information of different network element devices that report the device-side proxy function migration request through the cooperation of various functional modules in the dynamic message management device. That is, different network element devices are managed by different thread groups in a device deployed with a dynamic message management device, thereby realizing centralized management of multiple network element devices by one device and solving the technical problem of being unable to ensure data and management consistency due to distributed deployment of device-side agents.

[0095] In addition, since the network element information of each network element device that has completed the migration of the device-side proxy function is uniformly managed by the data management module, the SDN control equipment deployed with the dynamic message management device can communicate with each network element device that has completed the migration of the device-side proxy function in the future. It can realize accurate identification of the network element devices managed by each thread group based on the network element information managed in the data management module, and then realize communication with each network element device.

[0096] The fifth embodiment of the present application relates to a dynamic message management method, which is specifically applied to the SDN control device involved in the third embodiment.

[0097] The implementation details of the dynamic message management method of this embodiment are described below. The following content is only the implementation details provided for the convenience of understanding and is not necessary for implementing this solution.

[0098] The specific process of this embodiment is as follows Figure 6 As shown, the specific steps include:

[0099] Step 601, when the dynamic message scheduling module receives a device-side proxy function migration request reported by a network element device, it extracts the network element information of the network element device that reports the device-side proxy function migration request from the device-side proxy function migration request, and generates a creation instruction for creating a thread group of the network element device based on the network element information.

[0100] Specifically, when the SDN control device receives a reporting request from the device side, it is actually when the dynamic message scheduling module deployed in the SDN control device receives a device-side proxy function migration request reported by any network element device on the device side. Through the dynamic message scheduling module, it can be regarded as a code framework, which is specifically responsible for managing network element devices and interacting with network element devices, and dynamically creating the application modules required by each network element device according to the network element information of each network element device that reports the device-side proxy function migration request.

[0101] Step 602: The network element adaptation module creates according to the creation instruction and starts a thread group for managing the network element device.

[0102] Specifically, in practical applications, the network element adaptation module can be divided into a unified resource abstraction submodule and a link resource management submodule.

[0103] Therefore, what is said in step 602 is that the thread group that manages the network element device is created and started according to the creation instruction. Specifically, the unified resource abstraction submodule generates a unified resource abstraction thread according to the creation instruction, so that the unified resource abstraction thread abstracts the resource model corresponding to the network element device to obtain an abstract resource model; the link management submodule generates a link management thread according to the creation instruction, so that the link management thread allocates link resources to the abstract resource model and manages the link network element resources.

[0104] That is to say, every time the SDN control device manages a network element device, it will dynamically create a thread group specifically for managing the corresponding network element device, and then use the corresponding thread group to communicate with the network element device.

[0105] Step 603: The data management module manages the network element information.

[0106] Specifically, when the data management module manages the network element information of each network element device that completes the migration of the device-side proxy function, it assigns corresponding network element numbers to the network element devices according to the network element information of the network element devices according to preset rules, such as Arabic numerals 1, 2, 3, etc., or letters a, b, c, etc., which will not be repeated here and this embodiment does not limit this.

[0107] Furthermore, after the device-side proxy function of the network element device is moved to the SDN control device, the dynamic message management method provided in this embodiment can also delete the thread group that has been created to manage the network element device.

[0108] The methods for deleting thread groups are as follows:

[0109] The dynamic message scheduling module generates a deletion instruction for deleting the thread group that manages the network element device according to the network element information; and the network element adaptation module deletes the thread group that manages the network element device according to the deletion instruction.

[0110] It can be seen from the above description that the network element adaptation module can be divided into a unified resource abstraction submodule and a link resource management submodule.

[0111] Therefore, the above-mentioned operation of deleting the thread group is specifically that the unified resource abstraction submodule deletes the unified resource abstraction thread according to the deletion instruction, and the unified resource abstraction thread is used to abstract the resource model corresponding to the network element device to obtain an abstract resource model; the link resource management submodule deletes the link management thread according to the deletion instruction, and releases the link resources allocated to the abstract resource model, the link management thread.

[0112] Furthermore, in order to ensure the consistency between the existing thread group for managing network element devices and the network element devices managed in the data management module, after the network element adaptation module deletes the thread group for managing the network element devices according to the deletion instruction, the dynamic message scheduling module controls the data management module to modify the managed network element information and update the managed memory.

[0113] Regarding the above-mentioned data management module modifying the managed network element information and updating the managed memory, specifically: the data management module determines the network element number assigned to the network element device based on the network element information, and uses the network element number as an index to search for the network element information in the database, and clears the network element information.

[0114] Furthermore, while the SDN control device realizes centralized control over each network element device, it also needs to communicate with each managed network element device. In order to realize communication with each network element device, the communication process between the SDN control device and the managed network element device is as follows:

[0115] The data management module allocates a network element number to the network element device according to the network element information;

[0116] The dynamic message scheduling module selects, according to the network element number, a thread group that manages the network element device corresponding to the network element number from a plurality of thread groups for different network element devices managed by the network element adaptation module to obtain a target thread group;

[0117] The dynamic message scheduling module establishes communication with the alarm management module, the configuration management module, the resource query adaptation module, the data structure conversion module and the southbound adaptation communication interface module through the remote process scheduling module, and implements dynamic message scheduling between the alarm management module, the configuration management module, the resource query adaptation module, the data structure conversion module and the southbound adaptation communication interface module and the target thread group according to the network element number.

[0118] In order to facilitate the understanding of the ability to move the device-side proxy function to the SDN control device, and the communication between the SDN control device and each network element device after the device-side proxy function is moved up, the following is combined with Figure 1-3 The dynamic message management device shown in the figure systematically introduces the dynamic message management method provided by this embodiment, which is as follows:

[0119] Dynamic message scheduling module (hereinafter referred to as NeManager): performs unified life cycle management of the network element adaptation module (hereinafter referred to as NeCPA), including but not limited to creating, deleting, and modifying NeCPA instances (threads) based on the network element information of the network element device reported by the device-side agent function request, distributing Openflow messages based on the network element id, etc.; when a request to add management of a certain network element device is received, that is, a request to move up the device-side agent function reported by the network element device is received, the threads of the NeCPA instance are created in a chronological order, that is, the same resource abstraction thread (hereinafter referred to as TAP) and link management thread (hereinafter referred to as LRM) mentioned above; when a network element deletion message is received, the threads of the NeCPA instance are closed in a chronological order, and various memory and database storage data are managed.

[0120] It should be noted that the above-mentioned NeCPA is specifically implemented by transplanting the code of the original device-side agent function module, that is, the device-side agent function module originally deployed in the network element device.

[0121] In this embodiment, a group of threads acts as an agent for a network element device, provides an abstract function for the agent network element device, and a function for storing the abstracted data in a database.

[0122] Based on this method, one thread group manages one network element device, so that management of multiple network element devices can be achieved by creating and starting multiple thread groups in the SDN control device.

[0123] Furthermore, in actual applications, the internal SDN management and control equipment can limit the number of online threads through the thread pool, dynamically schedule threads according to external command calls, and pull relevant network element equipment resources for business conversion processing, thereby releasing the resources occupied by inactive network element equipment to meet larger-scale management needs.

[0124] Accordingly, regarding the device-side proxy function migration request, query request, and data object generation function reported by the network element device, the specific implementation is as follows:

[0125] When the network element device reports the addition or deletion of the network element list, NeManager generates network element management information after receiving the network element list information, and stores the network element information in the database in the memory. If it is a new network element device, that is, a thread group for managing the network element device is created, a TAP thread and an LRM thread are generated for the corresponding network element device, and the relevant network element number is generated and then stored in the corresponding global variable memory structure; if the network element device is deleted, the TAP thread and LRM thread corresponding to the network element device are deleted, and the relevant data is initialized at the same time, and then the data corresponding to the network element ID is reset to 0 from the memory, and the network element number is retained for subsequent use.

[0126] Regarding the scheduling, sending and receiving of messages, the specific implementation is as follows:

[0127] Each module sends messages to the TAP or LRM module, or between the TAP and LRM, by calling the interface provided by NeManager. In NeManager, each module implements the interface function of sending or receiving messages to TAP or LRM to forward messages. Each module finds the corresponding network element number in the memory of NeManager through the network element ID, and then generates the service type of the receiving thread through the network element number, that is, binds the socket.

[0128] In addition, for message sending, the message sending structure of all modules of the device-side proxy must add the network element number. The network element number is used to store the binding socket number of the message sent by each module, which is used for filtering when receiving.

[0129] For message reception, the socket is bound when the thread module is started to achieve message reception, ensuring the accuracy of message reception in different threads.

[0130] In addition, the functions of sequential startup of each module are specifically implemented as follows:

[0131] Initialization and startup of NeManager module; after external data recovery is completed, it enters working state, NeManager receives the network element list reported by the network management, generates network element management information after receiving the network element list information, and starts the TAP and LRM modules of each network element. At the same time, NeManager needs to filter the network element type and filter the network elements that do not need to be managed.

[0132] In order to better understand the startup sequence of the functional modules involved in the upward migration of the device-side agent, the following is combined with Figure 7 To explain:

[0133] NeManager receives the southbound adapter communication interface module ( Figure 7 After receiving the network element list information reported by COMS in the network, the network element management information is generated, and the corresponding TAP thread and LRM thread are started according to the network element management information.

[0134] Specifically, the startup process is as follows: NeManager first starts the TAP thread, specifically the unified resource abstraction submodule that manages the TAP thread initializes the corresponding TAP thread according to the network element management information provided by NeManager, and feeds back the initialization completion information to NeManager after the initialization is completed; then NeManager starts the LRM thread, specifically the link resource management submodule that manages the LRM thread initializes the corresponding LRM thread according to the network element management information provided by NeManager, and feeds back the initialization completion information to NeManager after the initialization is completed.

[0135] After the above two threads are started, NeManager first sends a ctrl work message to the LRM thread, and then after receiving the node id and link information reported by the LRM thread, it sends a ctrl work message to the TAP thread, and then receives the abstract resource model reported by the TAP thread to complete the startup.

[0136] The functions of deleting and adding network element devices are implemented as follows:

[0137] When the network management (the management and control cluster involved in the current network architecture) adds or deletes network element devices, it will notify the NeManager integrated in the SDN management and control device. For adding a thread group to manage network element devices, NeManager will start the NeCPA to create and start the TAP thread and LRM thread that manage the network element device.

[0138] For deleting network element devices and the thread group that manages the network element devices, after receiving the deletion request, NeManager will delete the threads corresponding to the network element devices. Specifically, it will delete the LRM thread first, then delete the TAP thread, and then reset the corresponding network element information and class structure information in the memory, and reset various identification bits.

[0139] It is not difficult to find from the above description that the dynamic message management method provided by this embodiment, when the dynamic message scheduling module receives the device side proxy function migration request reported by the network element device, extracts the network element information of the network element device that reports the request from the device side proxy function request, and generates a creation instruction for creating a thread group of the network element device that reports the device side proxy function request according to the network element information, and finally the network element adaptation module can create according to the creation instruction and start the thread group that manages the network element device that reports the device side proxy function request, thereby realizing the migration of the device side proxy function, that is, there is no need to deploy the device side proxy function separately in each network element device, and when realizing the migration of the device side proxy function, specifically according to the network element information of different network element devices that report the device side proxy function migration request, the thread group that manages each network element device is dynamically created, that is, different network element devices are managed by different thread groups in a device deployed with a dynamic message management device, thereby realizing the centralized management of multiple network element devices by one device, and solving the technical problem that the data and management consistency cannot be guaranteed due to the distributed deployment of the device side agent.

[0140] In addition, in the dynamic message management method proposed in the present application, since the network element information of each network element device that has completed the migration of the device-side proxy function is uniformly managed by the data management module, the device deployed with the dynamic message management device can communicate with each network element device that has completed the migration of the device-side proxy function in the future. It can realize accurate identification of the network element devices managed by each thread group based on the network element information managed in the data management module, and then realize communication with each network element device.

[0141] In addition, in the software-defined grid, the device-side proxy function is moved from the previous multiple device-side deployment to the control server side, that is, deployed in the SDN control device, and the code originally deployed in each network element device to implement the device-side proxy function is converted into a code that only needs to be deployed in the SDN control device to implement the device-side proxy function. While the device-side proxy function in the network element device is moved to the SDN control device and centrally managed by the SDN control device, partial communication between the device-side proxy and the SDN control device is realized through remote procedure calls. This solves the following existing technical problems:

[0142] 1. Considering the safety of equipment and network operations, telecom operators do not allow upgrading of equipment-side software, because upgrading may cause various problems such as service interruption and equipment instability. In this way, when there are problems with the equipment-side agent or when functions are expanded, bottlenecks will be encountered and cannot be effectively resolved;

[0143] 2. Existing older devices do not have device-side agents and cannot support new SDN functions. Even if the device side is upgraded, it cannot realize the ever-increasing new functions, resulting in many new functions of old devices being unusable.

[0144] 3. Once the equipment is deployed, the memory, hard disk, CPU, motherboard and other hardware and various supporting software cannot be upgraded. However, the demand for hardware and software is constantly increasing, which leads to the problem that the equipment gradually lags behind once it is launched.

[0145] 4. Since each device has a device-side agent, if a bug is found in the device-side agent, each device must be urgently upgraded. Even if the customer agrees, if there are hundreds of devices being managed, all of them must be upgraded. Not only is the upgrade time-consuming, but it is also possible that several of them will fail to upgrade, leading to immeasurable problems;

[0146] 5. The current distributed device-side agent management method cannot reflect the design concept of SDN centralized management, cannot be centrally managed, and has data and management consistency issues.

[0147] It is not difficult to find that this embodiment is a device embodiment corresponding to the first or second embodiment, and this embodiment can be implemented in conjunction with the first or second embodiment. The relevant technical details mentioned in the first or second embodiment are still valid in this embodiment, and in order to reduce repetition, they are not repeated here. Accordingly, the relevant technical details mentioned in this embodiment can also be applied in the first or second embodiment.

[0148] In addition, it should be understood that the step division of the above methods is only for clear description. When implemented, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent; adding insignificant modifications to the algorithm or process or introducing insignificant designs that do not change the core design of the algorithm and process are all within the scope of protection of this patent.

[0149] The sixth embodiment of the present application relates to a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the dynamic message management method described in the above method embodiment is implemented.

[0150] That is, those skilled in the art can understand that all or part of the steps in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a program, and the program is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0151] Those skilled in the art will appreciate that the above embodiments are specific embodiments for implementing the present application, and in actual applications, various changes may be made thereto in form and detail without departing from the spirit and scope of the present application.

Claims

1. A dynamic message management device, characterized in that: include: Dynamic message scheduling module, network element adaptation module and data management module; The dynamic message scheduling module is used to extract the network element information of the network element device that reported the device side proxy function move request from the device side proxy function move request when receiving the device side proxy function move request reported by the network element device, and generate a creation instruction for creating a thread group of the network element device according to the network element information; The network element adaptation module is used to create according to the creation instruction and start a thread group for managing the network element device, wherein the thread group includes a unified resource abstraction thread and a link management thread, the unified resource abstraction thread is used to abstract the resource model corresponding to the network element device to obtain an abstract resource model, and the link management thread is used to allocate link resources to the abstract resource model and manage the link resources; The data management module is used to manage the network element information.

2. The dynamic message management device according to claim 1, characterized in that: The dynamic message scheduling module is further used to generate a deletion instruction for deleting the thread group that manages the network element device according to the network element information; The network element adaptation module is further used to delete the thread group that manages the network element device according to the deletion instruction.

3. The dynamic message management device according to claim 2, characterized in that: The dynamic message scheduling module is also used to control the data management module to modify the managed network element information and update the managed memory after the network element adaptation module deletes the thread group managing the network element device according to the deletion instruction.

4. The dynamic message management device according to claim 3, characterized in that: The network element adaptation module includes: a unified resource abstraction submodule and a link resource management submodule; The unified resource abstraction submodule is used to generate the unified resource abstraction thread according to the creation instruction, or delete the unified resource abstraction thread according to the deletion instruction; The link resource management submodule is used to generate the link management thread according to the creation instruction; or, according to the deletion instruction, delete the link management thread and release the link resources allocated to the abstract resource model.

5. The dynamic message management device according to any one of claims 1 to 4, characterized in that: Also includes: Alarm management module, configuration management module and resource query adaptation module; The dynamic message scheduling module is further used to communicate with the alarm management module so that the alarm management module can implement alarm management of the network element device managed by the thread group; The dynamic message scheduling module is further used to communicate with the configuration management module so that the configuration management module implements the service configuration of the network element device managed by the thread group; The dynamic message scheduling module is also used to communicate with the resource query adaptation module so that the resource query adaptation module can respond to the resource query of the network element device managed by the thread group.

6. The dynamic message management device according to claim 5, characterized in that: Also includes: Data structure conversion module; The data structure conversion module is used to convert data of different structures received by the thread group created by the network element adaptation module to manage the network element device into a data structure that can be recognized by the dynamic message scheduling module, so that the dynamic message scheduling module distributes the converted data to the corresponding functional modules.

7. The dynamic message management device according to claim 6, characterized in that: Also includes: Southbound adapter communication interface module; The southbound adaptation communication interface module is used to send the data fed back by each functional module to the network element device managed by the thread group.

8. The dynamic message management device according to claim 7, characterized in that: Also includes: Remote procedure call module; The remote procedure call module is respectively communicated with the dynamic message scheduling module, the alarm management module, the configuration management module, the resource query adaptation module, the data structure conversion module and the southbound adaptation communication interface module, so that the dynamic message management device can realize dynamic message scheduling between the network element devices with the device-side agent function moved up.

9. The dynamic message management device according to claim 7, characterized in that: Also includes: A main control management module that is communicatively connected to the dynamic message scheduling module, the data structure conversion module, and the southbound adaptation communication interface module respectively; The main control management module is used to initialize the dynamic message scheduling module, the data structure conversion module and the southbound adaptation communication interface module, so that the dynamic message management device can realize the device-side agent migration or dynamic message scheduling between network element devices.

10. An SDN management and control device, characterized in that: include: An application service layer, a control service layer in communication connection with the application service layer, a device-side proxy layer in communication connection with the control service layer, and a data forwarding layer in communication connection with the device-side proxy layer; Wherein, the dynamic message management device as described in any one of claims 1 to 9 is deployed in the device-side proxy layer.

11. A dynamic message management system, characterized in that: include: The SDN control device as claimed in claim 10; and a plurality of network element devices communicatively connected to the SDN control device.

12. A dynamic message management method, characterized in that: Applied to the SDN management and control device according to claim 10, the method comprises: When receiving a device-side proxy function move-up request reported by a network element device, the dynamic message scheduling module extracts network element information of the network element device that reports the device-side proxy function move-up request from the device-side proxy function move-up request, and generates a creation instruction for creating a thread group of the network element device according to the network element information; The network element adaptation module is created according to the creation instruction, and starts a thread group for managing the network element device, wherein the thread group includes a unified resource abstraction thread and a link management thread, the unified resource abstraction thread is used to abstract the resource model corresponding to the network element device to obtain an abstract resource model, and the link management thread is used to allocate link resources to the abstract resource model and manage the link resources; The data management module manages the network element information.

13. The dynamic message management method according to claim 12, characterized in that: The network element adaptation module includes a unified resource abstraction submodule and a link resource management submodule; The network element adaptation module creates according to the creation instruction and starts a thread group for managing the network element device, including: The unified resource abstraction submodule generates the unified resource abstraction thread according to the creation instruction; The link resource management submodule generates the link management thread according to the creation instruction.

14. The dynamic message management method according to claim 12 or 13, characterized in that: The data management module manages the network element information, including: The data management module allocates a network element number to the network element device according to the network element information, and adds the network element number and the network element information to a database of a global variable memory structure by using the network element number as an index.

15. The dynamic message management method according to claim 12, characterized in that: The method further comprises: The dynamic message scheduling module generates a deletion instruction for deleting the thread group that manages the network element device according to the network element information; The network element adaptation module deletes the thread group that manages the network element device according to the deletion instruction.

16. The dynamic message management method according to claim 14, characterized in that: The network element adaptation module includes a unified resource abstraction submodule and a link resource management submodule; The unified resource abstraction submodule deletes the unified resource abstraction thread according to the deletion instruction of the thread group of the network element device, and the unified resource abstraction thread is used to abstract the resource model corresponding to the network element device to obtain an abstract resource model; The link resource management submodule deletes the link management thread according to the deletion instruction, and releases the link resources and the link management thread allocated to the abstract resource model.

17. The dynamic message management method according to claim 15 or 16, characterized in that: The method further comprises: After the network element adaptation module deletes the thread group managing the network element device according to the deletion instruction, the dynamic message scheduling module controls the data management module to modify the managed network element information and update the managed memory.

18. The dynamic message management method according to claim 17, characterized in that: The data management module modifies the managed network element information and updates the managed memory, including: The data management module determines the network element number allocated to the network element device according to the network element information, searches for the network element information in a database using the network element number as an index, and clears the network element information.

19. The dynamic message management method according to claim 12, characterized in that: The method further comprises: The data management module allocates a network element number to the network element device according to the network element information; The dynamic message scheduling module selects, according to the network element number, a thread group that manages the network element device corresponding to the network element number from a plurality of thread groups for different network element devices managed by the network element adaptation module to obtain a target thread group; The dynamic message scheduling module establishes communication with the alarm management module, the configuration management module, the resource query adaptation module, the data structure conversion module and the southbound adaptation communication interface module through the remote process scheduling module, and implements dynamic message scheduling between the alarm management module, the configuration management module, the resource query adaptation module, the data structure conversion module and the southbound adaptation communication interface module and the target thread group according to the network element number.

20. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the dynamic message management method according to any one of claims 12 to 19 is implemented.

Citation Information

Patent Citations

  • Multi-network element emulation test system and implementation method

    CN1805381A