Network device and method for tracking device configuration

Abstract

The invention relates to a device and a method for tracking device configuration changes in a network. The network includes a client for generating a device configuration change in response to configuration data. The client then pushes the device configuration change and the unique ID and the client ID to a server. The unique ID may be a transaction ID. And the client uses the unique ID as a southbound ID and stores the southbound ID in a configuration history of the southbound ID in combination with metadata of the configuration data. Correspondingly, the server takes the unique ID received from the client as a northbound ID, and stores the unique ID in a configuration history in combination with the client ID and the received metadata of the device configuration change. In this way, the device configuration change pushed to the server may be tracked based on the unique ID and the client ID.

Description

Technical Field

[0001] The present invention generally relates to the field of communication technology. For example, the present invention relates to a device and method for tracking the configuration of devices in a network. Background Art

[0002] Managing large-scale networks requires maintaining and updating a large number of network devices or network elements (NEs). For example, the device configuration of a NE needs to be updated to enable network services for new customers. Performing this device configuration update manually is error-prone and tedious.

[0003] To avoid the problem of manual updates, a network management system (NMS) is used to automatically update device configurations from high-level abstractions (such as service concepts). The NMS may include an orchestrator and a controller to convert high-level configurations of services into low-level configurations of NEs. The NMS typically updates the device configurations of the NE using a network configuration protocol, such as the Network Configuration Protocol (NETCONF) or the Representational State Transfer Configuration Protocol (RESTCONF). The YANG data modeling language is a data modeling language used to model services and / or configuration data of network management protocols.

[0004] In large-scale networks, multiple NMSs may coexist to handle various aspects of the network. Routine maintenance may still require network engineers to manually modify the device configuration of specific NEs. Automatically updated configuration changes in the network may bring unforeseen troubles and service interruptions, such as due to incorrect configuration, configuration conflicts from different NMSs, conflicting intentions from NMSs, etc.

[0005] Traditionally, network elements, controllers, and orchestrators keep the history of configuration changes locally. The history of configuration changes usually only includes local information, such as timestamps, user accounts, protocols, etc. In different network systems, the history of configuration changes can be called a configuration commit list or a configuration checkpoint. Summary of the invention

[0006] Network failures are often caused by incorrect or conflicting device configurations applied to network elements. As mentioned earlier, each NE only has information about the username that triggered the change, the protocol used to change the configuration, and the timestamp of the configuration change. Information about the reason why this configuration change was made is usually not available. Therefore, it is not easy to trace a service request from the network element, nor is it easy to immediately know whether the change in the service request was initiated by an external user outside the network or by automated software inside the network.

[0007] If the configuration change on the NE is performed by the automation software of the NMS, then finding out why the automation software made the configuration change usually requires correlating multiple sources of information in order to match the configuration change in the NMS with the specific configuration change on the NE. For example, if the change was done on the NE via NETCONF, the network engineer may need to check the configuration history of the NE and the configuration history of the controller to see if certain entries can be matched. Then, based on the timestamp, the corresponding entry can be found in the configuration history of the controller. This entry may include some useful information to determine why the device configuration was changed at that time. If necessary, it can be corrected accordingly. However, this mechanism requires network engineers to collect several sources of information, which is very time-consuming. This is too complex to be implemented in an automated manner. In addition, there are usually multiple controllers configuring multiple network elements in the network, and every possible pair of controllers and network elements may need to be checked.

[0008] As a result, it is difficult to trace a configuration change applied to a network element back to the root cause that triggered the configuration change. The root cause could be a specific service request that automatically triggered the configuration change, or a change that was manually initiated by a user.

[0009] In view of the above, the present invention aims to provide a solution to improve the traceability of device configuration changes in a network. An object of the present invention is to provide a solution to map device configuration changes to their original root causes. Another object of the present invention is to facilitate root cause analysis and self-healing in the network in case of failures.

[0010] These and other objects are achieved by the solutions of the invention as described in the independent claims. Advantageous implementations are further defined in the dependent claims.

[0011] A first aspect of the present invention provides a configuration sending device. The configuration sending device is used to generate a device configuration based on configuration data and configuration metadata of the configuration data. The configuration sending device is also used to generate a unique identifier (ID) associated with the configuration metadata. Then, the configuration sending device is used to store the configuration metadata in combination with the unique ID. Then, the configuration sending device is used to send the device configuration, the unique ID and a configurator ID identifying the configuration sending device to a configuration receiving device.

[0012] Optionally, the configuration sending device can be used to obtain configuration data before generating the device configuration. The configuration data can be understood as a model including a relatively high-level configuration of the configuration receiving device. The configuration sending device can be used to convert the configuration data into a device configuration of the configuration receiving device. That is, the device configuration is converted by the configuration sending device into a device configuration that can be directly applied to the configuration receiving device.

[0013] Optionally, the device configuration may include configuring one or more new parameters of the receiving device. Alternatively or additionally, the device configuration may include configuring one or more updated parameters of the receiving device. In the present invention, the device configuration may also include a device configuration change.

[0014] Optionally, the configuration sending device may be a client of a network configuration protocol, such as a NETCONF client or a RESTCONF client. In the present invention, the configuration sending device may be referred to as a "client". Accordingly, the configurator ID identifying the configuration sending device may be referred to as a "client ID". The configuration receiving device may be a server of a network configuration protocol, or a network device running such a server. For example, the configuration receiving device may be a NETCONF server or a RESTCONF server. In the present invention, the configuration receiving device may be referred to as a "server".

[0015] Optionally, the unique ID may include a value that is unique at least within the client. Alternatively, the unique ID may include a value that is unique in the network.

[0016] By storing the unique ID with the configuration metadata in the client, and sending the unique ID and configurator ID along with the device configuration to the server, the client can create a connection or association between the client and the server for this device configuration. Based on the unique ID and configurator ID, this device configuration can be traced back to the associated configuration metadata stored in the client, and finally to the corresponding configuration data. Therefore, an explicit and reliable mechanism can be provided to map configuration changes on the server to corresponding configuration data on the client based on the unique ID and configurator ID.

[0017] Optionally, the unique ID and configuration metadata may be stored as a single record of the client's configuration history.

[0018] In an implementation manner of the first aspect, the unique ID may include a transaction ID.

[0019] Optionally, the transaction ID can be a unique ID shared between the server and the client for each device configuration transaction. The transaction ID can also be used for synchronization between the server and the client. Optionally, the transaction ID can be an extension of the NETCONF protocol.

[0020] By associating the configuration metadata with the transaction ID as a unique ID, the transaction ID that can be used for configuration synchronization can be reused to map configuration changes to configuration data. Therefore, there is no need to create additional IDs, which can further reduce signaling overhead.

[0021] In an implementation manner of the first aspect, the configuration data may include a service request.

[0022] Optionally, the service request may include information about the deployment and / or implementation request of the service. The client may also be configured to convert the service request into a device configuration that enables the server to transmit the requested service. The device configuration may include one or more configuration and operating parameters, or a change to one or more configuration and operating parameters.

[0023] Alternatively, the service request may be obtained from a higher level network device relative to the configuration sending device. Alternatively, the service request may be generated by a network operator or an operations support system (OSS) / business support system (BSS). Alternatively, the service request may be entered manually.

[0024] By mapping device configuration to service request using unique ID, it is easy to determine which service request triggered the device configuration and whether the service request was automatically generated within the network or manually entered by an external user (or customer). Therefore, it helps to achieve self-healing of the network during root cause analysis (RCA).

[0025] In an implementation of the first aspect, the configuration metadata may include one or more of the following:

[0026] - Configuration ID;

[0027] - Timestamp;

[0028] - User information;

[0029] - A method for performing said device configuration.

[0030] The configuration ID can be a unique ID within the client and uniquely identifies the configuration data on the client. The configuration ID can also be called a commit ID. Methods for performing device configuration can include command-line interface (CLI), SMP, NETCONF, and RESTCONF.

[0031] Optionally, the client can also be used to store configuration data.

[0032] In an implementation manner of the first aspect, the configuration sending device may be a network orchestration entity, configured to send the device configuration to a network controller serving as the configuration receiving device.

[0033] The network orchestration entity may also be referred to as an orchestrator. An orchestrator may be used to indicate one or more network controllers and may have a wider view of a portion of a network or the entire network than the one or more network controllers.

[0034] In an implementation manner of the first aspect, the configuration sending device may be a network controller, configured to send the device configuration to a network element serving as the configuration receiving device.

[0035] A second aspect of the present invention provides a configuration receiving device. The configuration receiving device is used to receive a device configuration, a unique ID associated with the device configuration, and a configurator ID identifying the configuration sending device from a configuration sending device. The configuration receiving device is then used to generate configuration metadata of the device configuration and store the configuration metadata in combination with the unique ID and the configurator ID.

[0036] Configuring the receiving device can also be used to apply device configuration. By storing the configuration metadata in conjunction with the unique ID and the configurator ID, the device configuration applied to the server can be retroactively mapped to the corresponding configuration data on the client. Therefore, it helps to find out what triggered the device configuration. Therefore, it can help to achieve self-healing of the network during RCA.

[0037] In an implementation of the second aspect, the unique ID may include a transaction ID. Optionally, the server may also be configured to synchronize device configuration with the client based on the transaction ID.

[0038] In an implementation of the second aspect, the configuration metadata may include one or more of the following:

[0039] - a configuration ID identifying the device configuration;

[0040] - Timestamp;

[0041] - User information;

[0042] - A method for performing said device configuration.

[0043] The configuration ID may be an ID that is unique only on the server and uniquely identifies the corresponding device configuration on the server. Methods for performing device configuration may include CLI, SMP, NETCONF, and RESTCONF.

[0044] In an implementation manner of the second aspect, the configuration receiving device may be a network controller, configured to receive the device configuration from a network orchestration entity serving as the configuration sending device.

[0045] In an implementation manner of the second aspect, the configuration receiving device may be a network element, configured to receive the device configuration from a network controller serving as the configuration sending device.

[0046] A third aspect of the present invention provides a system, which includes one or more configuration sending devices according to the first aspect or any implementation thereof, and one or more configuration receiving devices according to the second aspect or any implementation thereof.

[0047] In an implementation manner of the third aspect, the system may include at least one network orchestration entity, at least one network controller, and at least one network element.

[0048] It should be noted that at least one network orchestration entity may be coupled to at least one network controller. At least one network controller may be coupled to at least one network element. That is, at least one network orchestration may act as a client relative to at least one network controller acting as a server. At least one network controller may act as a client relative to at least one network element acting as a server.

[0049] A fourth aspect of the present invention provides a use of the system. The use is used to track device configurations in a communication network. The use comprises the following steps:

[0050] - Send a request to query configuration changes to the configuration receiving device;

[0051] - receiving one or more pieces of configuration metadata for one or more device configurations;

[0052] - target configuration metadata identifying the target device configuration;

[0053] - Obtaining a unique ID associated with the target configuration data and a configurator ID identifying the configuration sending device;

[0054] - Sending a request for querying configuration changes to the configuration sending device based on the configurator ID;

[0055] - Identifying corresponding configuration data stored on the configuration sending device based on the unique ID.

[0056] Optionally, the use may be performed by an analysis entity of the network, which may be used to perform a root cause analysis.

[0057] In an implementation of the fourth aspect, the identified configuration data may include a service request or a change request for an existing service.

[0058] By retroactively tracking the target device configuration change to the configuration data using a unique ID, the root cause that triggered the target device configuration can be easily and explicitly identified. If the configuration data including the service request is automatically generated, a corresponding fix can be performed. If the configuration data is manually entered, such as by an external user outside the network, it can be identified that the root cause is from outside the network. A corresponding fix can also be performed.

[0059] A fifth aspect of the present invention provides a method comprising the following steps:

[0060] -Configure the sending device to generate a device configuration based on the configuration data;

[0061] - the configuration sending device generates configuration metadata for the configuration data;

[0062] - the configuration sending device generates a unique ID associated with the configuration metadata;

[0063] - the configuration sending device stores the configuration metadata in combination with the unique ID;

[0064] - The configuration sending device sends the device configuration, the unique ID and a configurator ID identifying the configuration sending device to the configuration receiving device.

[0065] In an implementation of the fifth aspect, the unique ID may include a transaction ID.

[0066] In an implementation manner of the fifth aspect, the configuration data may include a service request.

[0067] In an implementation of the fifth aspect, the configuration metadata may include one or more of the following:

[0068] - Configuration ID;

[0069] - Timestamp;

[0070] - User information;

[0071] - A method for performing said device configuration.

[0072] In an implementation manner of the fifth aspect, the configuration sending device may be a network orchestration entity, configured to send the device configuration to a network controller serving as the configuration receiving device.

[0073] In an implementation manner of the fifth aspect, the configuration sending device may be a network controller, configured to send the device configuration to a network element serving as the configuration receiving device.

[0074] The method of the fifth aspect and its implementation manner can achieve the same advantages and effects as described above for the configuration sending device of the first aspect and its implementation manner.

[0075] A sixth aspect of the present invention provides a method comprising the following steps:

[0076] - A configuration receiving device receives a device configuration, a unique ID associated with the device configuration, and a configurator ID identifying the configuration sending device from a configuration sending device;

[0077] - the configuration receiving device generates configuration metadata of the device configuration;

[0078] - said configuration receiving device stores said configuration metadata in conjunction with said unique ID and said configurator ID.

[0079] In an implementation of the sixth aspect, the unique ID may include a transaction ID.

[0080] In an implementation manner of the sixth aspect, the configuration metadata may include one or more of the following items:

[0081] - Configuration ID;

[0082] - Timestamp;

[0083] - User information;

[0084] - A method for performing said device configuration.

[0085] In an implementation manner of the sixth aspect, the configuration receiving device may be a network controller, configured to receive the device configuration from a network orchestration entity that serves as the configuration sending device.

[0086] In an implementation manner of the sixth aspect, the configuration receiving device may be a network element, configured to receive the device configuration from a network controller serving as the configuration sending device.

[0087] The method of the sixth aspect and its implementation method can achieve the same advantages and effects as described above for the configuration receiving device of the second aspect and its implementation method.

[0088] A seventh aspect of the present invention provides a computer program, comprising instructions, which, when the program is executed by a computer, cause the computer to execute the method according to the fifth aspect or any implementation thereof.

[0089] An eighth aspect of the present invention provides a computer program, comprising instructions, which, when the program is executed by a computer, cause the computer to execute the method according to the sixth aspect or any implementation thereof.

[0090] A ninth aspect of the present invention provides a non-transitory storage medium that stores executable program code. When the executable program code is executed by a processor, the method described in the fifth aspect or any of its implementations is performed.

[0091] The tenth aspect of the present invention provides a non-transitory storage medium that stores executable program code. When the executable program code is executed by a processor, the method described in the sixth aspect or any of its implementations is executed.

[0092] It should be noted that all devices, elements, units and modules described in this application can be implemented in software or hardware elements or any combination thereof. All steps performed by various entities described in this application and the functions described to be performed by various entities are intended to indicate that the corresponding entity is suitable for or used to perform the corresponding steps and functions. Although in the description of the following specific embodiments, the specific functions or steps performed by the external entity are not reflected in the description of the specific detailed elements of the entity that performs the specific steps or functions, it should be clear to the technician that these methods and functions can be implemented in the corresponding hardware or software elements or any combination thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0093] In conjunction with the accompanying drawings, the following description of specific embodiments will illustrate the above aspects and their implementation methods, wherein:

[0094] Figure 1 The configuration sending device provided by the present invention is shown;

[0095] Figure 2 The configuration receiving device provided by the present invention is shown;

[0096] Figure 3 An example of a network provided by the present invention is shown;

[0097] Figure 4 An example of configuration history stored on a network device provided by the present invention is shown;

[0098] Figure 5 Another example of the network provided by the present invention is shown;

[0099] Figure 6 Another example of configuration history stored on a network device provided by the present invention is shown;

[0100] Figure 7 An example of the self-healing process provided by the present invention is shown;

[0101] Figure 8 A diagram illustrating the method of the present invention;

[0102] Fig. 9 A diagram illustrating another method of the present invention. DETAILED DESCRIPTION

[0103] The present invention can be used in various networks, such as but not limited to networks based on software-defined networking (SDN), autonomous networks and autonomous driving networks (ADN). The present invention can generally be applied to any network configuration protocol, such as but not limited to NETCONF and RESTCONF protocols.

[0104] The present invention generally relates to tracking device configuration changes within a network. In the present invention, a configuration sending device may be referred to as a client, and a configuration receiving device may be referred to as a server.

[0105] Figure 1 The client 100 provided by the present invention is shown. The client 100 is used to generate a device configuration based on configuration data 101. Then, the client is used to send the device configuration to the server.

[0106] In order to keep a record of the configuration data 101, the client is further configured to generate configuration metadata for the configuration data 101. The configuration metadata may be part of a device configuration history, where the client 100 keeps a history of configuration changes.

[0107] The client 100 is also used to generate a unique ID. The client 100 is also used to store configuration metadata in conjunction with the unique ID. Optionally, the unique ID can be an ID that is at least unique to the client. That is, the unique ID can be an ID that uniquely identifies the configuration data and / or configuration metadata on the client. For example, client A pushes device configuration to server B and server C in response to the received configuration data. Client A and server B can share a unique ID with a value of 1. Client A and server C can also share the same unique ID with a value of 1. In this case, from server B and server C, the pushed device configuration can be traced back to the corresponding configuration metadata stored on client A based on the combination of (client ID A, unique ID 1).

[0108] Alternatively, the unique ID may be unique within the network. For example, when client A and server B share a unique ID with a value of 1, another unique ID with a value of 2 should be used between client A and server C. In this case, client 100 may be configured to store configuration metadata in combination with two or more unique IDs.

[0109] The client 100 is also used to send the device configuration 103, the unique ID and the client ID to the server.

[0110] It should be noted that the device configuration, unique ID, and client ID may be sent in a single message 103 or in separate messages ( Figure 1 The data is sent in (not shown).

[0111] It should also be noted that the client 100 can be used to store the configuration metadata in combination with the unique ID after sending the device configuration 103 to the server. In some optional cases, such as a two-phase commit protocol, the client 100 can be used to wait for confirmation from the server that the device configuration 103 has been successfully applied. After receiving the confirmation, the client 100 can be used to store the configuration metadata in combination with the unique ID. Optionally, when there are two or more servers, the client 100 can be used to wait for confirmation from all servers to be received, and then store the configuration metadata in combination with the unique ID.

[0112] Optionally, the unique ID may be a transaction ID. The transaction ID may be an extension of the NETCONF protocol to maintain synchronization between the server and the client. When stored in conjunction with configuration metadata, the unique ID that the client 100 stores in its device configuration history may be referred to as a southbound ID or southbound transaction ID.

[0113] Alternatively, for example, the client ID may be a MAC address of the client, an IP address of the client, a hardware ID of the client, or a network ID of the client.

[0114] For example, the single message 103 sent by the client 100 to the server may be an IP message. The IP message may include the MAC address of the client 100 in the header field, which may be used indirectly as the client ID. The payload of the IP message may include the device configuration and the unique ID. Optionally, the payload of the IP message may also directly include the client ID. The device configuration, the unique ID, and the client ID may be in the format of extensible markup language (XML) or JavaScript object notation (JSON). Optionally, the device configuration, the unique ID, and the client ID may be sent using the YANG data modeling language in XML tree format.

[0115] Optionally, the client 100 may include a receiving module 110, a sending module 130, a processor 120, a memory 140, and a storage medium 160. The receiving module 110 may be used to receive configuration data 101. The sending module 130 may be used to send device configuration 103, a unique ID, and a client ID. The memory 140 may be used to store instructions that, when executed by the processor 120, cause the client 100 to perform device configuration generation, configuration metadata generation, unique ID generation, and other related steps. The storage medium 160 may be a long-term storage for storing configuration metadata in conjunction with a unique ID. The long-term storage may include a non-volatile memory, such as a hard disk drive, a solid-state drive, and / or a flash memory.

[0116] Optionally, the receiving module 110 may be referred to as a “northbound interface”, and the sending module 130 may be referred to as a “southbound interface.” The receiving module 110 and the sending module 130 may be part of a transceiver module.

[0117] Optionally, the northbound interface may be used to communicate with a higher level network device, while the southbound interface may be used to communicate with a lower level network device.

[0118] Figure 2 The server 200 provided by the present invention is shown. The server 200 is used to receive data from a client (e.g. Figure 1 The client 100) receives the device configuration, the unique ID associated with the device configuration, and the client ID. Optionally, the device configuration, the unique ID, and the client ID may be in the same Figure 1 The message 103 corresponds to the single message 201 received. The corresponding elements may also share the same features and functions.

[0119] In order to save a record of the received device configuration, the server 200 is further configured to generate configuration metadata of the received device configuration. The configuration metadata may be part of the device configuration history, where the server 200 saves the history of configuration changes.

[0120] The server 200 is then used to store the configuration metadata in conjunction with the unique ID. Optionally, the unique ID may be a transaction ID. When stored in conjunction with the configuration metadata, the unique ID received from the client and stored by the server 200 may be referred to as a northbound ID in the device configuration history of the server 200.

[0121] Optionally, the device configuration change may generate a chain reaction in the network. That is, if the server 200 is coupled to another network device at a lower level, the server 200 may act as Figure 1 , and provides another device configuration, another unique ID, and the ID of the server 200 to the other network device in another message 203. That is, Figure 1 Client 100 and Figure 2 The servers 200 can be cascaded.

[0122] Optionally, the server 200 may include a receiving module 210, a sending module 230, a processor 220, a memory 240, and a storage medium 260. The receiving module 210 may be used to receive a device configuration, a unique ID, and a client ID. The sending module 230 may be used to send another message 203 to a lower-level network device. The memory 240 may be used to store instructions that, when executed by the processor 220, cause the server 200 to perform configuration metadata generation and other related steps. The storage medium 260 may be a long-term storage for storing configuration metadata in combination with the unique ID and the client ID. The long-term storage may include a non-volatile memory, such as a hard disk drive, a solid-state drive, and / or a flash memory.

[0123] Optionally, the receiving module 210 may be referred to as a “northbound interface”, and the sending module 230 may be referred to as a “southbound interface.” The receiving module 210 and the sending module 230 may be part of a transceiver module.

[0124] Optionally, the northbound interface can be used to communicate with higher-level network devices (such as Figure 1 The southbound interface can be used to communicate with lower-level network devices.

[0125] Figure 3 3 shows an example of a network provided by the present invention. The network includes a client 310 and a server 320. The client 310 is based on Figure 1 The client 100 is built, and the server 320 is based on Figure 2 The corresponding elements may also share the same features and functions.

[0126] A network (e.g., SDN) may include network devices such as orchestrators, controllers, and network elements. An orchestrator may be a network entity that receives service requests and implements service requests by configuring southbound systems such as controllers and network elements. A controller may be a network entity configured by a northbound system such as an orchestrator to configure southbound systems such as network elements and other controllers. Both an orchestrator and a controller may be referred to as an NMS. A network element may be referred to as a device involved in network data transmission and may be configured by an NMS. For example, a network element may be a router or a switch.

[0127] In a first possible scenario, client 310 may be an orchestrator and server 320 may be a controller. The orchestrator may be used to receive configuration data 301, for example, from a customer or service provider. Configuration data 301 may include a service request. The service request may indicate operational and deployment requirements for the service. For example, the service request may indicate modifying, adding, or deleting a service.

[0128] Then, the orchestrator is used to generate configuration metadata 312 for configuration data 301. Configuration metadata 312 may include a configuration ID that uniquely identifies configuration data 301 on the orchestrator, a timestamp of when configuration data 301 is received, and user information about a user who provides configuration data 301.

[0129] The orchestrator is then used to generate a device configuration for the controller based on the configuration data. The orchestrator may be used to generate a unique ID 313. The unique ID 313 may be a transaction ID, which may be used as a version number to keep the configurations between the orchestrator and the controller synchronized. This transaction ID is unique within the orchestrator. Alternatively, the orchestrator may be used to use the configuration ID as the transaction ID, as they are both unique within the orchestrator. That is, typically, in the present invention, optionally, the value of the configuration ID may be used as the value of the unique ID or the transaction ID.

[0130] The orchestrator is then used to store the unique ID 313 in conjunction with the configuration metadata 312 .

[0131] The orchestrator is used to send a unique ID 313 (e.g., a transaction ID), a device configuration, and an orchestrator ID to the controller, for example, via a single message 303. It should be noted that the unique ID 313 sent to a higher-level network device (e.g., server 320) can be referred to as the southbound ID 313 of client 310.

[0132] Then, the controller as server 320 is used to receive the device configuration, unique ID 313 and the orchestrator. It should be noted that the unique ID 313 received from the higher-level network device (eg, client 310) can be referred to as the northbound ID 323 of the server 320.

[0133] Then, the controller is used to generate configuration metadata 322 of the device configuration, and stores the generated configuration metadata 322 in combination with the northbound ID 323 and the orchestrator ID 324. The northbound ID 323 stored on the controller corresponds to the southbound ID 313 stored on the orchestrator. Therefore, a mapping relationship can be created, and device configuration changes can be tracked.

[0134] The configuration metadata 322 of the controller may include a configuration ID that uniquely identifies a device configuration on the controller, a timestamp of when the device configuration was received or applied, user information about a user who applied the device configuration, and a method used to apply the device configuration.

[0135] In a second possible scenario, the client 310 may be a controller and the server 320 may be a network element. The controller may be configured to receive configuration data 301 from the orchestrator. The configuration data 301 may include a device configuration of the controller. The controller may be configured to apply the device configuration and convert the device configuration into a device configuration of the network element.

[0136] Other aspects of the second possible situation should be similar to those of the first possible situation and will not be described in detail here.

[0137] Figure 4 An example of the configuration history on the network device provided by the present invention is shown. Figure 4 and Figure 3 Correspondingly, a client 310 and two servers 320, 320' are shown. A single northbound transaction received by the client 310 may trigger the configuration of the two servers 320, 320'. It should be noted that the network of the present invention may include at least one server and at least one client.

[0138] from Figure 4 It can be seen that in the configuration history of the client 310, the southbound transaction ID is stored in combination with the corresponding configuration metadata. Correspondingly, in the configuration history of the servers 320, 320', the northbound transaction ID is stored in combination with the corresponding configuration metadata. The southbound ID of the client 310 and the northbound ID of the servers 320, 320' correspond to each other. This can create a mapping relationship between the configuration data of the client 310 and the device configuration of the servers 320, 320', which facilitates RCA within the network.

[0139] Figure 5 Another example of a network provided by the present invention is shown. The network includes at least one orchestrator 510, at least one controller 520, and at least one network element 530.

[0140] Figure 5 Shows Figure 3 Therefore, the corresponding elements can also share the same functions and features.

[0141] Specifically, orchestrator 510 is used to obtain a service request as configuration data 501, and generate device configuration 502 of controller 520. Orchestrator 510 is used to generate a first transaction ID as a first southbound ID 513, and first configuration metadata 512. First southbound ID 513 is stored in combination with first configuration metadata 513.

[0142] After receiving the device configuration 502, the first transaction ID, and the orchestrator ID, the controller 520 is used to generate second configuration metadata 522 for the device configuration. The first transaction ID received from the orchestrator 510 is stored by the controller 520 as a first northbound ID 523 in combination with the second configuration metadata 522 and the orchestrator ID 525. The first southbound ID 513 corresponds to the first northbound ID 523. That is, they both include the same unique ID, namely the first transaction ID.

[0143] Then, the controller 520 also acts as a client of the network element 530. That is, the controller 520 is also used to convert its device configuration 502 into the device configuration 503 of the network element 530. Then, the controller 520 generates a second transaction ID.

[0144] Then, the controller 520 is used to store the second transaction ID as the second southbound ID 524 in combination with the second configuration metadata 522. Therefore, both the first northbound ID 523 and the second southbound ID 524 may be stored in combination with the second configuration metadata 522.

[0145] Then, the controller 520 is used to send the second transaction ID, the device configuration 503 of the network element 530, and the controller ID to the network element 530. The network element 530 is used to generate the third configuration metadata 532 accordingly, and store the second transaction ID as the third northbound ID 534 in combination with the third configuration metadata 532 and the controller ID 535. The third northbound ID 534 corresponds to the second southbound ID 524. That is, they both include the same unique ID, namely the second transaction ID.

[0146] In this way, the unique ID shared between the server and the client can provide a mapping relationship. The device configuration 503 of the network element 530 corresponding to the third configuration metadata 532 can be traced back to the service request corresponding to the first configuration metadata 512 through the first transaction ID and the second transaction ID.

[0147] It should be noted that, in the present invention, the location or order of storing the northbound ID, southbound ID and configuration metadata is not strictly limited, as long as they are stored in a single record of the corresponding device configuration history.

[0148] Figure 6 Another example of the configuration history on the network device provided by the present invention is shown. Figure 6 and Figure 5 Correspondingly, an orchestrator, a controller and two network elements (NE 1 and NE 2) are used as an example for explanation.

[0149] from Figure 6It can be seen that based on transaction ID 2 stored in NE 1 (or NE 2), it can be traced all the way back to transaction ID 1 stored in the orchestrator. The corresponding configuration data stored on the orchestrator can then be determined, and the root cause that triggered the device configuration on NE 1 or NE 2 can be determined. The root cause could be an automated request generated within the network or a manually entered request from an external entity outside the network.

[0150] Figure 7 The purpose of the system for tracking device configuration changes provided by the present invention is shown. The system includes a network management system (NMS1) as a client, two network elements (NE 1 and NE 2) as servers, and an RCA entity that supports automatic resolution of configuration issues.

[0151] The use may include the following steps:

[0152] Step 701: Detect faults on NE 1 and NE 2;

[0153] Step 702: Send a request to query the most recent configuration change, such as the last configuration change before the failure occurs;

[0154] Step 703: Obtain northbound transaction ID and NMS ID;

[0155] Step 704: Obtain configuration data on NMS1 based on the northbound transaction ID (corresponding to the southbound transaction ID on NMS1) and the NMS ID;

[0156] Step 705: Solve the configuration problem through closed-loop automation.

[0157] This enables automatic resolution of configuration issues and provides self-healing of the network.

[0158] Figure 8 A diagram of a method 800 of the present invention is shown. The method 800 comprises the following steps:

[0159] - Step 801: The configuration sending device generates a device configuration based on the configuration data;

[0160] - Step 802: The configuration sending device generates configuration metadata of the configuration data;

[0161] - Step 803: The configuration sending device generates a unique ID associated with the configuration metadata;

[0162] - Step 804: The configuration sending device stores the configuration metadata in combination with the unique ID;

[0163] - Step 805: The configuration sending device sends the device configuration, the unique ID and the configurator ID identifying the configuration sending device to the configuration receiving device.

[0164] It should be noted that the order of executing steps 801, 802 and 803 can be interchanged. The order of executing steps 804 and 805 can be interchanged.

[0165] Optionally, the method may include:

[0166] - Step 806: The configuration sending device receives confirmation of successful application of the sent device configuration from the configuration receiving device.

[0167] In this case, step 804 may be performed after receiving the confirmation. That is, steps 804, 805, and 806 may be performed in the following order: step 805, step 806, and step 804.

[0168] From the above description for the client Figures 1 to 7 From the perspective of FIG. 8 , the steps of method 800 may share the same functions and details. Therefore, the corresponding method implementation will not be described in detail herein.

[0169] Fig. 9 A diagram of a method 900 of the present invention is shown. The method 900 comprises the following steps:

[0170] - Step 901: The configuration receiving device receives a device configuration, a unique identifier (ID) associated with the device configuration, and a configurator ID identifying the configuration sending device from the configuration sending device;

[0171] - Step 902: The configuration receiving device generates configuration metadata of the device configuration;

[0172] - Step 903: The configuration receiving device stores the configuration metadata in combination with the unique ID and the configurator ID.

[0173] From the description above for the server Figures 1 to 7 From the perspective of FIG. 1 , the steps of method 900 may share the same functions and details. Therefore, the corresponding method implementation will not be described in detail here.

[0174] In the present invention, the transaction ID can be used by the NETCONF server to check whether the configuration on the client has been changed, thereby avoiding a full synchronization cycle. The transaction ID can be the best candidate for the unique ID of the present invention. By recording the transaction ID on both ends of each transaction (i.e., the client and the server), and using the transaction record to match the configuration changes applied to the server with the original configuration data on the client that triggered the device configuration change. Optionally, the configuration ID generated on the client can be reused as a transaction ID.

[0175] For example, in a scenario where the orchestrator configures the controller and the controller configures the network element, the orchestrator generates a transaction ID for transaction #1 and saves it as the southbound transaction ID. The service request that triggers transaction #1 and the generated transaction ID (southbound transaction ID) are saved as a single record in the orchestrator's configuration history. The orchestrator then sends the generated transaction ID in transaction #1, which contains its own ID and the controller's device configuration.

[0176] After receiving transaction #1, the controller saves the transaction ID of transaction #1 as the northbound transaction ID and generates another transaction ID for transaction #2 for the network element. The metadata of the controller's device configuration, along with the northbound ID, southbound ID, and orchestrator ID, are saved as a single record in the controller's configuration history. The controller sends the generated another transaction ID in transaction #2, which contains its own ID and the network element's device configuration.

[0177] After receiving transaction #2, the network element records the applied changes by saving the metadata of its device configuration, the northbound ID (another transaction ID), and the controller ID as a single record in the network element's configuration history.

[0178] To track configuration changes on the network element to the original service request, the analysis entity may perform the following steps:

[0179] -Query the configuration history of the network element to find records including the configuration change, northbound transaction ID (another transaction ID) and controller ID;

[0180] - Based on the controller ID, identify the controller to which the configuration change is pushed;

[0181] -Query the controller's configuration history to obtain the ID of another transaction ID as a record of the southbound transaction ID and obtain the corresponding orchestration

[0182] Device ID and northbound transaction ID (transaction ID);

[0183] - Based on the orchestrator ID, identify the orchestrator that pushed the configuration change;

[0184] -Query the orchestrator's configuration history to get the record with the transaction ID as the southbound transaction ID and get the original service request.

[0185] This way, configuration changes applied to lower-level network devices can be automatically mapped to configuration data in higher-level network devices. Therefore, device configuration changes can be tracked in the network.

[0186] In the present invention, the device (including the server and the client) may include a processor or a processing circuit (not shown) for executing, implementing or starting various operations of the device described herein. The processing circuit may include hardware and / or the processing circuit may be controlled by software. The hardware may include an analog circuit or a digital circuit, or both an analog circuit and a digital circuit. The digital circuit may include components such as an application-specific integrated circuit (ASIC), a field-programmable array (FPGA), a digital signal processor (DSP) or a multi-purpose processor. The device may also include a memory circuit that stores one or more instructions that can be executed by a processor or a processing circuit, for example, under the control of software. For example, the memory circuit may include a non-transient storage medium that stores executable software code, which, when executed by a processor or a processing circuit, performs various operations of the device. In one embodiment, the processing circuit includes one or more processors and a non-transient memory connected to the one or more processors. The non-transient memory may carry an executable program code, and when one or more processors execute the executable program code, the executable program code causes the device to execute, implement or start the operation or method described herein.

[0187] The invention has been described in conjunction with various embodiments and implementations as examples. However, those skilled in the art will be able to understand and implement other variations when implementing the claimed subject matter based on a study of the drawings, the invention and the independent claims. In the claims and in the specification, the word "comprising" does not exclude other elements or steps, and "a" or "an" does not exclude a plurality. A single element or other unit may fulfil the functions of several entities or items described in the claims. The enumeration of certain measures in mutually different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. A configuration sending device (310), characterized in that: Used for: Generating a device configuration (303) based on the configuration data (301); Generating configuration metadata (312) of the configuration data (301); generating a unique identifier (ID) (313) associated with the configuration metadata (312); storing the configuration metadata (312) in conjunction with the unique ID (313); The device configuration (303), the unique ID (313) and a configurator ID identifying the configuration sending device are sent to a configuration receiving device (320).

2. The configuration sending device according to claim 1, characterized in that: The unique ID (313) includes a transaction ID.

3. The configuration sending device according to claim 1 or 2, characterized in that: The configuration data (301) includes a service request.

4. The configuration sending device according to any one of claims 1 to 3, characterized in that: The configuration metadata includes one or more of the following: - Configuration ID; - Timestamp; - User information; - A method for performing said device configuration.

5. The configuration sending device according to any one of claims 1 to 4, characterized in that: The configuration sending device (310) is a network orchestration entity, and is used to send the device configuration (303) to a network controller serving as the configuration receiving device (320).

6. The configuration sending device according to any one of claims 1 to 4, characterized in that: The configuration sending device (310) is a network controller, which is used to send the device configuration (303) to a network element serving as the configuration receiving device (320).

7. A configuration receiving device (320), characterized in that: Used for: receiving, from a configuration sending device (310), a device configuration (303), a unique identifier (ID) (323) associated with the device configuration (303), and a configurator ID (324) identifying the configuration sending device; Generating configuration metadata (322) of the device configuration (303); The configuration metadata (322) is stored in conjunction with the unique ID (323) and the configurator ID (324).

8. The configuration receiving device according to claim 7, characterized in that: The unique ID (323) includes a transaction ID.

9. The configuration receiving device according to claim 7 or 8, characterized in that: The configuration metadata (322) includes one or more of the following: - Configuration ID; - Timestamp; - User information; - A method for performing said device configuration.

10. The configuration receiving device according to any one of claims 7 to 9, characterized in that: The configuration receiving device (320) is a network controller, which is used to receive the device configuration from a network orchestration entity which is the configuration sending device (310).

11. The configuration receiving device according to any one of claims 7 to 9, characterized in that: The configuration receiving device (320) is a network element, which is used to receive the device configuration from a network controller which is the configuration sending device (310).

12. A system, characterized in that: The method comprises one or more configuration sending devices according to any one of claims 1 to 6, and one or more configuration receiving devices according to any one of claims 7 to 11.

13. The system according to claim 12, characterized in that The system includes at least one network orchestration entity, at least one network controller and at least one network element.

14. Use of a system according to claim 12 or 13 for tracking device configurations within a communication network, characterized in that: The use comprises the following steps: Sending (702) a request to query configuration changes to a configuration receiving device; receiving one or more pieces of configuration metadata for one or more device configurations; target configuration metadata identifying a target device configuration; Acquire (703) a unique ID associated with the target configuration data and a configurator ID identifying a configuration sending device; Sending (704) a request to query configuration changes to a configuration sending device based on the configurator ID; The corresponding configuration data stored on the configuration sending device is identified (705) based on the unique ID.

15. Use of the system according to claim 14, characterized in that The identified configuration data includes a service request.

16. A method (800), characterized in that include: The configuration sending device generates (801) a device configuration based on the configuration data; The configuration sending device generates (802) configuration metadata of the configuration data; The configuration sending device generates (803) a unique identifier (ID) associated with the configuration metadata; The configuration sending device stores (804) the configuration metadata in conjunction with the unique ID; The configuration sending device sends (805) the device configuration, the unique ID, and a configurator ID identifying the configuration sending device to the configuration receiving device.

17. A method (900), characterized in that include: A configuration receiving device receives (901) a device configuration, a unique identifier (ID) associated with the device configuration, and a configurator ID identifying the configuration sending device from a configuration sending device; The configuration receiving device generates (902) configuration metadata of the device configuration; The configuration receiving device stores (903) the configuration metadata in conjunction with the unique ID and the configurator ID.

18. A computer program, characterized in that The method comprises a program code, which executes the method according to claim 16 or 17 when the program code is run on a computer.

Images