Data change notification method, netconf server, netconf client and storage medium

Abstract

Provided in the present application are a data change notification method, a NETCONF server, a NETCONF client and a storage medium. The data change notification method comprises: a NETCONF server performing capability negotiation with a NETCONF client, and informing the NETCONF client of the capability thereof for supporting incremental data notifications; when a data change event has occurred, determining a target node where the data change has occurred and a target value corresponding to the target node; then encapsulating the target node and the target value corresponding to the target node to an incremental data notification message; and then sending the incremental data notification message to the NETCONF client, so as to report a data change notification to the NETCONF client.

Description

Data change notification method, NETCONF server, NETCONF client, and storage media

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based on the Chinese patent application with application number 202311238563.X and application date September 22, 2023, and claims the priority of the Chinese patent application. The entire content of the Chinese patent application is hereby introduced into this application as a reference. Technical Field

[0003] The present application relates to the field of communication technology, and in particular to a data change notification method, a NETCONF server, a NETCONF client, and a storage medium. Background Art

[0004] The Network Configuration Protocol (NETCONF) provides a mechanism for managing network devices. Users can use this mechanism to add, modify, and delete the configuration of network devices and obtain configuration and status information of network devices.

[0005] YANG PUSH uses the NETCONF client / server communication model to encapsulate user data of interest into notification messages and report them to users on a scheduled basis or according to trigger conditions. Device configuration and status data can be expressed using YANG models. Clients can use YANG to dynamically obtain device configuration and status data and wish to dynamically detect changes in configuration or status data or monitor changes in certain key data. YANG PUSH provides a mechanism for proactively reporting device YANG model data to clients periodically based on subscription conditions. Based on the user's subscription request message, the device periodically and proactively reports the user's data of interest to the designated data recipient, using the reporting method and data type specified in the message.

[0006] According to the YANG PUSH protocol, once a NETCONF client subscribes to data store change notifications, whenever data in the data store changes, the NETCONF server will report a notification message using the "push-change-update" notification format defined in the YANG PUSH protocol. This notification message must identify not only the value change of the data store node, but also the type of change since the last update. Currently, the YANG PUSH protocol has the following issues: The protocol uses the "replace" operation to identify object value changes. However, if the change is minor, such as changes to the values ​​of multiple leaf nodes in a container or list, a replace change notification for the container or list must be reported, which will include multiple nodes whose data has not changed. Reporting a replace change notification for a leaf node requires multiple change notifications. This is unnecessary, as redundant notification data wastes resources, increases the burden on the NETCONF client, and hinders network maintenance and operation.

[0007] Summary of the Invention

[0008] Embodiments of the present application provide a data change notification method, a NETCONF server, a NETCONF client, and a storage medium, aiming to at least reduce data redundancy in data change notifications.

[0009] In a first aspect, an embodiment of the present application provides a data change notification method, which is applied to a network configuration protocol NETCONF server, and the method includes:

[0010] Performing capability negotiation with a NETCONF client, notifying the NETCONF client of its ability to support incremental data notification;

[0011] In response to a data change event, determining a target node where the data change occurs and a target value corresponding to the target node;

[0012] Encapsulating the target node and the target value corresponding to the target node into an incremental data notification message;

[0013] Send an incremental data notification message to the NETCONF client.

[0014] In a second aspect, an embodiment of the present application provides a data change notification method, which is applied to a network configuration protocol NETCONF client, and the method includes:

[0015] Performing capability negotiation with the NETCONF server to confirm that the NETCONF server is capable of supporting incremental data notification.

[0016] Receiving an incremental data notification message sent by the NETCONF server, wherein the incremental data notification message includes a target node and a target value corresponding to the target node, the target node indicating a data node where data has changed in the NETCONF server, and the target value indicating a value of the target node after the data has changed;

[0017] According to the incremental data notification message, the local value of the target node is updated to the target value.

[0018] In a third aspect, an embodiment of the present application provides a network configuration protocol NETCONF server, including:

[0019] one or more processors;

[0020] A memory having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the data change notification method as described in the first aspect above.

[0021] In a fourth aspect, an embodiment of the present application provides a network configuration protocol NETCONF client, including:

[0022] one or more processors;

[0023] A memory having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the data change notification method as described in the second aspect above.

[0024] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the data change notification method as described in the first aspect above, or the data change notification method as described in the second aspect above.

[0025] In an embodiment of the present application, a capability negotiation is performed between the NETCONF server and the NETCONF client. The NETCONF server notifies the NETCONF client of its ability to support incremental data notifications. When a data change event occurs, the NETCONF server determines the target node where the data change occurred and the target value corresponding to the target node. The target node and the target value corresponding to the target node are then encapsulated into an incremental data notification message. The incremental data notification message is then sent to the NETCONF client, thereby reporting the data change notification to the NETCONF client. Since only the target node where the data change occurred and the target value corresponding to the target node are encapsulated when encapsulating the incremental data notification message, the amount of data carried by the data change notification message is reduced, thereby reducing data redundancy in the data change notification. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] FIG1 is a schematic diagram of a NETCONF network architecture provided in an embodiment of the present application;

[0027] FIG2 is a schematic diagram of the steps of a data change notification method provided in an embodiment of the present application;

[0028] FIG3 is a schematic diagram of a process of capability interaction between a NETCONF server and a NETCONF client provided in an embodiment of the present application;

[0029] FIG4 is a schematic diagram of a process of capability interaction and incremental data notification message subscription between a NETCONF server and a NETCONF client provided in an embodiment of the present application;

[0030] FIG5 is a schematic diagram of the steps of a data change notification method provided in an embodiment of the present application;

[0031] FIG6 is a schematic diagram of the steps of a data change notification method provided in Example 1 of the present application;

[0032] FIG7 is a schematic diagram of the steps of a data change notification method provided in Example 2 of the present application;

[0033] FIG8 is a schematic diagram of the architecture of a NETCONF server provided in an embodiment of the present application;

[0034] FIG9 is a schematic diagram of the architecture of a NETCONF client provided in an embodiment of the present application. DETAILED DESCRIPTION

[0035] In order to enable those skilled in the art to better understand the technical solution of the present application, the data change notification method, electronic device and computer-readable storage medium provided by the present application are described in detail below with reference to the accompanying drawings.

[0036] Hereinafter, example embodiments will be described more fully in conjunction with the accompanying drawings, but the described example embodiments may be embodied in different forms and should not be construed as limited to the embodiments set forth herein. Rather, these examples are provided so that this application will be thorough and complete and will fully enable those skilled in the art to understand the scope of this application.

[0037] As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0038] The terms used herein are used only to describe specific embodiments and are not intended to limit this application. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms, unless the context clearly indicates otherwise. It will also be understood that when the terms "comprising" and / or "made of" are used in this specification, they specify the presence of features, wholes, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or groups thereof.

[0039] In the description of the embodiments of the present application, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it can be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.

[0040] In the description of the embodiments of this application, any embodiment or design scheme using "exemplary," "for example," or "for example" should not be understood as being more preferred or advantageous than other embodiments or designs. Rather, the use of words such as "exemplary," "for example," or "for example" is intended to present the relevant concepts in a concrete manner.

[0041] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly identifying the technical features being referred to. Thus, features specified as "first" or "second" may explicitly or implicitly include one or more of such features. The terms "include," "comprising," "having," and their variations all mean "including but not limited to," unless otherwise specifically emphasized.

[0042] In order to facilitate understanding of the solutions of the embodiments of the present application and to provide a clear and concise description of the following embodiments, a brief introduction to the relevant technologies is first given.

[0043] NETCONF provides a mechanism for managing network devices. Users can use this mechanism to add, modify, and delete the configuration of network devices, and obtain the configuration and status information of network devices. Please refer to Figure 1, which is a schematic diagram of a NETCONF network architecture provided by an embodiment of the present application. As shown in Figure 1, the NETCONF network architecture includes at least one network management device / controller and at least one network device. The network management device / controller acts as a client in the network and uses the NETCONF protocol to perform system management on the network devices. Send to the network device <rpc>Request, query, or modify the values ​​of one or more specific parameters. Receive alarms and events from network devices to understand the current status of managed devices. Network devices act as servers in the network, maintaining information about managed devices and responding to requests from network management devices / controllers, reporting management data to the requesting network management devices / controllers. A NETCONF session is a logical connection between a network management device / controller and a network device. Network devices must support at least one NETCONF session.

[0044] Network management devices / controllers obtain information from running network devices, including configuration and status data. They manipulate the configuration data to migrate the network devices to the desired state. The NETCONF protocol primarily focuses on how network management devices / controllers manipulate configuration data and does not address how configuration data is stored on network devices.

[0045] The network management device / controller is called the NETCONF client, and the managed network device is called the NETCONF server. The NETCONF client must successfully establish a secure, connection-oriented session with the server before communication can proceed. The NETCONF client sends an RPC request to the NETCONF server. After processing the request, the NETCONF server sends a response message to the NETCONF client. Both the NETCONF client's RPC request and the NETCONF server's response are encoded in XML.

[0046] YANG is a data modeling language designed specifically for the NETCONF protocol. It is used to design operational configuration data, state data models, remote procedure calls (RPCs) models, and notification mechanisms for the NETCONF protocol. The YANG data model is a machine-oriented model interface that explicitly defines data structures and their constraints, enabling more flexible and complete data descriptions.

[0047] NETCONF Notification is a subscription and reporting mechanism for alarms and events based on the NETCONF protocol, providing an asynchronous reporting service for alarms and events based on a data model. YANG provides the Notification keyword to model this notification mechanism. Unlike the "send-receive" mechanism of RPC messages, which relies on the client to query data, NETCONF Notification proactively reports alarms or events to the client via Notification messages when the server occurs. It is primarily used in scenarios that require real-time awareness of device status, such as reporting alarms and events to network management systems via the NETCONF protocol.

[0048] YANG PUSH uses the NETCONF client / server communication model to encapsulate user data of interest into Notifications and report them to users on a scheduled basis or according to trigger conditions. Device configuration and status data can be expressed using YANG models. Clients can use YANG to dynamically obtain device configuration and status data and wish to dynamically detect changes in configuration or status data or monitor changes in certain key data. YANG PUSH provides a mechanism for proactively reporting device YANG model data to clients periodically based on subscription conditions. Based on the user's subscription request message, the device periodically and proactively reports the user's data of interest to the designated data recipient according to the reporting method and data type specified in the message.

[0049] According to the YANG PUSH protocol, once a NETCONF client subscribes to data store change notifications, whenever the data in the data store changes, the NETCONF server will report a notification message according to the "push-change-update" notification format defined in the YANG PUSH protocol. The notification message must not only identify the value change of the data store node, but also the type of change since the last update. Currently, the YANG PUSH protocol has the following issues: the protocol mentions the use of the "replace" operation to identify object value changes. However, if the change is minor, such as changes to the values ​​of multiple leaf nodes in a container or list, a replace change notification for the container or list must be reported, which will include multiple nodes whose data has not changed. Reporting a replace change notification for a leaf node requires reporting multiple change notifications, which may lead to data redundancy. For example, a list node contains N non-critical leaf nodes, where N is greater than 1. The values ​​of M of these non-critical leaf nodes change, and 0 < M < N. According to the current standard protocol, the NETCONF server must report M notifications, each reporting a changed leaf node and its corresponding value. Alternatively, the NETCONF server reports a single notification containing N leaf nodes and their corresponding values, including both changed and unchanged nodes. This approach generates redundant notification data, resulting in unnecessary resource waste, increasing the burden on NETCONF clients, and hindering network maintenance and operation.

[0050] In view of this, embodiments of the present application provide a data change notification method, a NETCONF server, a NETCONF client, and a computer-readable storage medium, aiming to at least reduce data redundancy in data change notifications.

[0051] In an embodiment of the present application, a capability negotiation is performed between the NETCONF server and the NETCONF client. The NETCONF server notifies the NETCONF client of its ability to support incremental data notifications. When a data change event occurs, the NETCONF server determines the target node where the data change occurred and the target value corresponding to the target node. The target node and the target value corresponding to the target node are then encapsulated into an incremental data notification message. The incremental data notification message is then sent to the NETCONF client, thereby reporting the data change notification to the NETCONF client. Since only the target node where the data change occurred and the target value corresponding to the target node are encapsulated when encapsulating the incremental data notification message, the amount of data carried by the data change notification message is reduced, thereby reducing data redundancy in the data change notification.

[0052] The data change notification method, NETCONF server, NETCONF client, and computer-readable storage medium provided in the embodiments of the present application are specifically illustrated by the following embodiments. First, the data change notification method in the embodiments of the present application is described.

[0053] Please refer to Figure 2, which is a schematic diagram of the steps of a data change notification method provided in an embodiment of the present application. The method is executed by the NETCONF server. As shown in Figure 2, the data change notification method includes the following steps S110-S140. Each step is described in turn below:

[0054] In step S110 , the NETCONF server performs capability negotiation with the NETCONF client and notifies the NETCONF client that it has the capability to support incremental data notification.

[0055] In the embodiment of the present application, the NETCONF server first notifies the NETCONF client that it has the ability to support incremental data notification, so as to facilitate the NETCONF client to implement incremental data notification management on the NETCONF server. For example, after the NETCONF client learns that the NETCONF server has the ability to support incremental data notification, it can send an incremental data subscription request message to the NETCONF server, and the NETCONF server returns a message carrying the incremental data to the NETCONF client. <ok>The incremental data subscription response message of the element indicates that the incremental data notification subscription is successful. In this way, when data changes occur on the NETCONF server side, the NETCONF server proactively reports the incremental data of the changed data to the NETCONF client.

[0056] In one possible implementation, the NETCONF server performs capability negotiation with the NETCONF client to notify the NETCONF client that it has the ability to support incremental data notification, specifically including the following steps: the NETCONF server sends a Hello message carrying an incremental data notification capability identifier to the NETCONF client, so that the NETCONF client confirms that the NETCONF server has the ability to support incremental data notification based on the incremental data notification capability identifier in the Hello message.

[0057] It can be understood that the NETCONF server sends a Hello message to the NETCONF client. The Hello message carries the capability identifier of the capabilities supported by the NETCONF server, and the capability identifier includes the incremental data notification capability identifier. In this way, after the NETCONF client receives the Hello message sent by the NETCONF server, it can learn from the incremental data notification capability identifier in the Hello message that the NETCONF server has the ability to support incremental data notification.

[0058] Exemplarily, the process of capability negotiation between the NETCONF server and the NETCONF client may also include the following steps: the NETCONF server receives a Hello message sent by the NETCONF client that carries an incremental data notification capability identifier; the NETCONF server confirms that the NETCONF client has the ability to support incremental data notification based on the incremental data notification capability identifier in the received Hello message.

[0059] Please refer to Figure 3, which is a schematic diagram of the process of capability interaction between a NETCONF server and a NETCONF client provided by an embodiment of the present application. As shown in Figure 3, after the NETCONF server and the NETCONF client establish a NETCONF session, they send Hello messages to each other to announce the capability sets they support. The Hello messages sent by the NETCONF server and the NETCONF client both carry the incremental data notification capability identifier, that is, the NETCONF server and the NETCONF client both support the incremental data notification capability. After confirming that they support the incremental data notification capability, the NETCONF client sends an incremental data subscription request message to the NETCONF server, and the NETCONF server returns a Hello message carrying the incremental data notification capability identifier to the NETCONF client. <ok>The incremental data subscription response message of the element indicates that the incremental data notification subscription is successful. When data changes occur on the NETCONF server, the NETCONF server proactively reports the incremental data of the changed data to the NETCONF client.

[0060] In another possible implementation, the NETCONF server performs capability negotiation with the NETCONF client and notifies the NETCONF client that it has the capability to support incremental data notification. The implementation specifically includes the following steps: the NETCONF server receives a subscription message carrying an incremental data indication parameter sent by the NETCONF client, wherein the incremental data indication parameter is used to instruct the NETCONF client to subscribe to incremental data notification messages from the NETCONF server; the NETCONF server returns a subscription success message to the NETCONF client, so that the NETCONF client confirms that the NETCONF server has the capability to support incremental data notification based on the subscription success message.

[0061] Please refer to Figure 4, which is a schematic diagram of the process of capability interaction and incremental data notification message subscription between a NETCONF server and a NETCONF client provided by an embodiment of the present application. As shown in Figure 4, the NETCONF server receives the subscription message sent by the NETCONF client, and the NETCONF server confirms that the subscription message represents a subscription request for the incremental data notification message based on the incremental data indication parameter carried in the subscription message. If the NETCONF server itself has the ability to support incremental data notification, the NETCONF server returns the message carrying the incremental data notification message to the NETCONF client. <ok>The NETCONF client sends a response message (i.e., a subscription success message) to the NETCONF server to confirm that the incremental data notification message has been successfully subscribed to. After receiving the subscription success message, the NETCONF client confirms that the NETCONF server supports incremental data notification.

[0062] Exemplarily, after receiving the subscription message sent by the NETCONF client, the NETCONF server further includes the following steps: the NETCONF server confirms, based on the subscription message, that the NETCONF client has the capability to support incremental data notification.

[0063] It can be understood that the NETCONF client will only send a subscription message carrying the incremental data indication parameter to the NETCONF server when the NETCONF client itself has the ability to support incremental data notification. Therefore, when the NETCONF server receives the subscription message carrying the incremental data indication parameter, it can learn that the NETCONF client has the ability to support incremental data notification. After the NETCONF client returns a subscription success message, it triggers a data change event occurring on the server and sends an incremental data notification message to the NETCONF client.

[0064] The subscription message of the NETCONF client can carry <rpc>Message identifier, the response message of the NETCONF server carries <rpc>Message ID consistent <rpc-reply>Message ID, indicating that the reply message is a reply to the subscription message with the message ID.

[0065] Exemplarily, the subscription message may also be a subscription creation message or a subscription modification message.

[0066] In one embodiment, the NETCONF client sends a subscription message with a message identifier of "101" to the NETCONF server. The subscription message includes <establish-subscription>Element, indicating that the subscription message is a subscription creation message and contains incremental data indication parameters <merge>, indicating that the subscription creation message is a subscription creation request for incremental data; after receiving the subscription message, the NETCONF server, if it has the ability to support incremental data notification, returns a response message containing a message identifier "101" to the NETCONF client. The response message carries <ok>Element, indicating that the subscription creation request for the incremental data notification message has been confirmed. If the NETCONF server itself does not support the incremental data notification capability, it can return a response message containing the message identifier "101" to the NETCONF client. The response message carries <rpc-error>This element indicates that the NETCONF client's request to create a subscription for incremental data notification messages is rejected.

[0067] In another embodiment, the NETCONF client sends a subscription message with a message identifier of "101" to the NETCONF server, and the subscription message includes <modify-subscription>Element, indicating that the subscription message is a subscription modification message and contains incremental data indication parameters <merge>, indicating that the subscription modification message is a request to modify the data change notification message to the incremental data notification message format; after the NETCONF server receives the subscription message, if it has the ability to support incremental data notification, it returns a response message containing the message identifier "101" to the NETCONF client. The response message carries <ok>Element, indicating that the data change notification message has been confirmed to be modified into the incremental data notification message format. If the NETCONF server itself does not support the incremental data notification capability, it can return a response message containing the message identifier "101" to the NETCONF client. The response message carries <rpc-error>This element indicates that the NETCONF client's request to modify the data change notification message into an incremental data notification message is rejected.

[0068] In step S120 , the NETCONF server determines the target node where the data change occurs and the target value corresponding to the target node in response to the data change event.

[0069] In step S130 , the NETCONF server encapsulates the target node and the target value corresponding to the target node into an incremental data notification message.

[0070] After the NETCONF server and the NETCONF client agree on the incremental data notification capability, if a data change event occurs on the server, it determines the data node where the data change occurred, sets the data node where the data change occurred as the target node, and uses the target node's value after the data change as the target value. The target node and target value are then encapsulated in an incremental data notification message, ignoring data nodes whose values ​​have not changed. In other words, an incremental data notification message only carries data nodes where data has changed and their changed values; data nodes whose values ​​have not changed are not included in the incremental data notification message.

[0071] Exemplarily, in response to a data change event, the NETCONF server determines a target node where data has changed and a target value corresponding to the target node. This includes: in response to a data change occurring at any one or more data nodes in a YANG model file, the NETCONF server identifies the data node where data has changed as the target node and identifies the data node where data has not changed as a non-target node; the NETCONF server identifies the value corresponding to the target node after the data change as the target value. The NETCONF server encapsulates the target node and the target value corresponding to the target node into an incremental data notification message.

[0072] Illustratively, the data node may be a leaf-list node, a leaf node, a list node, or a container node.

[0073] For example, a list node has N non-critical leaf nodes, of which the values ​​of M non-critical leaf nodes change. According to existing standards, M notification messages need to be reported, and each message reports a changed leaf node and its changed value; or one notification message is reported, and the notification reports N leaf nodes and their values, and the N nodes include changed nodes and unchanged nodes. After optimization of the embodiment of the present application, this configuration change can report a notification message containing M changed leaf nodes and their changed values, which reduces M-1 notifications compared to reporting M notification messages; and the number of nodes in the notification is NM less compared to reporting a notification containing N nodes. When the configuration of the server changes frequently or the number of nodes contained in the list node is large, the optimization effect of the embodiment of the present application is significant.

[0074] Step S140: The NETCONF server sends an incremental data notification message to the NETCONF client.

[0075] Exemplarily, the incremental data notification message carries an incremental data notification message identifier.

[0076] In an embodiment of the present application, the NETCONF server negotiates capabilities with the NETCONF client, notifying the NETCONF client of its ability to support incremental data notifications. When a data change event occurs, the server determines the target node where the data change occurred and the target value corresponding to the target node. The server then encapsulates the target node and the target value corresponding to the target node into an incremental data notification message, which is then sent to the NETCONF client to report the data change notification to the NETCONF client. Since only the target node where the data change occurred and the target value corresponding to the target node are encapsulated when encapsulating the incremental data notification message, the amount of data carried by the data change notification message is reduced, thereby reducing data redundancy in the data change notification.

[0077] Please refer to Figure 5, which is a schematic diagram of the steps of a data change notification method provided in an embodiment of the present application. The method is executed by a NETCONF client. As shown in Figure 5, the data change notification method includes the following steps S210-S230. Each step is described in turn below:

[0078] In step S210 , the NETCONF client performs capability negotiation with the NETCONF server to confirm that the NETCONF server has the capability to support incremental data notification.

[0079] For example, the NETCONF client conducts capability negotiation with the NETCONF server to determine whether the NETCONF server has the capability to support incremental data notification, so as to facilitate the notification management of data changes on the NETCONF server. For example, after the NETCONF client learns that the NETCONF server has the capability to support incremental data notification, it can send an incremental data subscription request message to the NETCONF server, and the NETCONF server returns a message carrying the incremental data subscription request to the NETCONF client. <ok>The incremental data subscription response message of the element indicates that the incremental data notification subscription is successful. In this way, when data changes occur on the NETCONF server side, the NETCONF server proactively reports the incremental data of the changed data to the NETCONF client.

[0080] In one possible implementation, the NETCONF client confirms that the NETCONF server has the ability to support incremental data notification by performing capability negotiation with the NETCONF server, specifically including the following steps: the NETCONF client receives a Hello message sent by the NETCONF server that carries an incremental data notification capability identifier; the NETCONF client determines that the NETCONF server has the ability to support incremental data notification based on the incremental data notification capability identifier in the received Hello message.

[0081] Exemplarily, the process of capability negotiation between the NETCONF client and the NETCONF server may further include the following steps: the NETCONF client sends a Hello message carrying an incremental data notification capability identifier to the NETCONF server, so that the NETCONF server determines that the NETCONF client has the capability to support incremental data notification based on the incremental data notification capability identifier in the Hello message.

[0082] For example, after the NETCONF server and the NETCONF client establish a NETCONF session, they send Hello messages to each other to announce the capability sets they support. The Hello messages sent by the NETCONF server and the NETCONF client both carry the incremental data notification capability identifier, that is, the NETCONF server and the NETCONF client both support the incremental data notification capability. After confirming that they support the incremental data notification capability, the NETCONF client sends an incremental data subscription request message to the NETCONF server, and the NETCONF server returns a Hello message carrying the incremental data notification capability identifier to the NETCONF client. <ok>The incremental data subscription response message of the element indicates that the incremental data notification subscription is successful. When data changes occur on the NETCONF server, the NETCONF server proactively reports the incremental data of the changed data to the NETCONF client.

[0083] In another possible implementation, the NETCONF client confirms that the NETCONF server has the ability to support incremental data notification by performing capability negotiation with the NETCONF server, specifically including the following steps: the NETCONF client sends a subscription message carrying an incremental data indication parameter to the NETCONF server, where the incremental data indication parameter is used to instruct the NETCONF client to subscribe to incremental data notification messages from the NETCONF server; the NETCONF client receives a subscription success message returned by the NETCONF server based on the subscription message; the NETCONF client determines, based on the subscription success message, that the NETCONF server has the ability to support incremental data notification.

[0084] Exemplarily, the NETCONF server confirms, based on the subscription message, that the NETCONF client has the capability to support incremental data notification.

[0085] It can be understood that the NETCONF client will only send a subscription message carrying the incremental data indication parameter to the NETCONF server when the NETCONF client itself has the ability to support incremental data notification. Therefore, when the NETCONF server receives the subscription message carrying the incremental data indication parameter, it can learn that the NETCONF client has the ability to support incremental data notification. After the NETCONF client returns a subscription success message, it triggers a data change event occurring on the server and sends an incremental data notification message to the NETCONF client.

[0086] Exemplarily, the subscription message includes a subscription creation message or a subscription modification message.

[0087] For example, the subscription message of the NETCONF client can carry <rpc>Message identifier, the response message of the NETCONF server carries <rpc>Message ID consistent <rpc-reply>Message ID, indicating that the reply message is a reply to the subscription message with the message ID.

[0088] In one embodiment, the NETCONF client sends a subscription message with a message identifier of "101" to the NETCONF server. The subscription message includes <establish-subscription>Element, indicating that the subscription message is a subscription creation message and contains incremental data indication parameters <merge>, indicating that the subscription creation message is a subscription creation request for incremental data; after receiving the subscription message, the NETCONF server, if it has the ability to support incremental data notification, returns a response message containing a message identifier "101" to the NETCONF client. The response message carries <ok>Element, indicating that the subscription creation request for the incremental data notification message has been confirmed. If the NETCONF server itself does not support the incremental data notification capability, it can return a response message containing the message identifier "101" to the NETCONF client. The response message carries <rpc-error>This element indicates that the NETCONF client's request to create a subscription for incremental data notification messages is rejected.

[0089] In another embodiment, the NETCONF client sends a subscription message with a message identifier of "101" to the NETCONF server, and the subscription message includes <modify-subscription>Element, indicating that the subscription message is a subscription modification message and contains incremental data indication parameters <merge>, indicating that the subscription modification message indicates that the data change notification is changed to the incremental data notification format; after the NETCONF server receives the subscription message, if it has the ability to support incremental data notification, it returns a response message containing the message identifier "101" to the NETCONF client. The response message carries <ok>Element, indicating that the data change notification message has been confirmed to be modified into the incremental data notification message format. If the NETCONF server itself does not support the incremental data notification capability, it can return a response message containing the message identifier "101" to the NETCONF client. The response message carries <rpc-error>This element indicates that the NETCONF client's request to modify the data change notification message to the incremental data notification message format is rejected.

[0090] In step S220, the NETCONF client receives an incremental data notification message sent by the NETCONF server, where the incremental data notification message includes a target node and a target value corresponding to the target node. The target node represents the data node where data has changed in the NETCONF server, and the target value represents the value of the target node after the data has changed.

[0091] In step S230 , the NETCONF client updates the local value of the target node to the target value according to the incremental data notification message.

[0092] Exemplarily, the data node is a leaf list node, a leaf node, a list node, or a container node.

[0093] Exemplarily, the incremental data notification message does not include non-target nodes, and non-target nodes represent data nodes on which no data changes have occurred on the NETCONF server.

[0094] Exemplarily, in response to a data change on any one or more data nodes in a YANG model file, the NETCONF server identifies the data node with the data change as the target node and the data node without the data change as the non-target node. The NETCONF server then uses the value of the target node after the data change as the target value. The NETCONF server encapsulates the target node and its corresponding target value into an incremental data notification message and then sends the incremental data notification message to the NETCONF client. After receiving the incremental data notification message, the NETCONF client obtains the incremental data from the incremental data notification message, namely the target node and its corresponding target value. It then locally updates the value of the target node to the target value, thereby synchronizing the data on the NETCONF server.

[0095] The technical solutions of the embodiments of the present application are described in detail below through specific examples.

[0096] Example 1:

[0097] Please refer to FIG6 , which is a schematic diagram of the steps of a data change notification method provided in Example 1 of this application. The method includes the following steps:

[0098] In step S801, the NETCONF client sends a hello message 1 to the NETCONF server. The hello message 1 carries the NETCONF client's capability set to notify the NETCONF server of its supported capabilities. The capability set includes an incremental data notification capability identifier. The NETCONF client confirms that the NETCONF server has the capability to support incremental data notification based on the incremental data notification capability identifier.

[0099] In step S802, the NETCONF server sends a hello message 2 to the NETCONF client. The hello message 2 carries the NETCONF server's capability set to notify the NETCONF client of its supported capabilities. The capability set includes an incremental data notification capability identifier. The NETCONF server confirms that the NETCONF client has the capability to support incremental data notification based on the incremental data notification capability identifier.

[0100] Step S803: The NETCONF client subscribes to incremental data notification from the NETCONF server.

[0101] Step S804: The NETCONF server returns a subscription response message to the NETCONF client, indicating that the subscription to the incremental data notification is successful.

[0102] Step S805: In response to a data change event occurring on the server, the NETCONF server determines a target node where the data change occurred and a target value corresponding to the target node.

[0103] Step S806: The NETCONF server ignores the data nodes where no data changes have occurred, and encapsulates the target node and the target value corresponding to the target node into an incremental data notification message.

[0104] Step S807: The NETCONF server sends an incremental data notification message to the NETCONF client. The incremental data notification message carries an incremental data notification message identifier. In response, the NETCONF client receives the message from the NETCONF server and determines that the message is an incremental data notification message based on the incremental data notification message identifier carried in the message.

[0105] Step S808: The NETCONF client obtains the target node and the target value corresponding to the target node from the incremental data notification message;

[0106] Step S809: The NETCONF client updates the local value of the target node to the target value.

[0107] In Example 1 above, the NETCONF client and server exchange hello messages, exchanging their respective capabilities to confirm that both parties support incremental data notification. When data changes on the NETCONF server, the target node and its corresponding target value are encapsulated in an incremental data notification message, which is then sent to the NETCONF client. Upon receiving the incremental data notification message, the NETCONF client obtains the target node and its corresponding target value from the message and updates the local value of the target node to the target value, thereby synchronizing the data on the NETCONF server.

[0108] Example 2:

[0109] Please refer to FIG7 , which is a schematic diagram of the steps of a data change notification method provided in Example 2 of this application. The method includes the following steps:

[0110] Step S901: The NETCONF client sends a subscription message to the NETCONF server, where the subscription message carries an incremental data indication parameter.

[0111] Step S902: The NETCONF server receives a subscription message from the NETCONF client, confirms that the NETCONF client has subscribed to the incremental data notification based on the incremental data indication parameter in the subscription message, and returns a subscription success message to the NETCONF client.

[0112] Step S903: The NETCONF client receives a subscription success message from the NETCONF server, and confirms, based on the subscription success message, that the NETCONF server has the capability to support incremental data notification.

[0113] Step S904: In response to a data change event occurring on the server, the NETCONF server determines a target node where the data change occurred and a target value corresponding to the target node.

[0114] Step S905: The NETCONF server ignores the data nodes where no data changes have occurred, and encapsulates the target node and the target value corresponding to the target node into an incremental data notification message.

[0115] Step S906: The NETCONF server sends an incremental data notification message to the NETCONF client. The incremental data notification message carries an incremental data notification message identifier.

[0116] Step S907: The NETCONF client receives the message from the NETCONF server and determines that the message is an incremental data notification message based on the incremental data notification message identifier carried in the message.

[0117] Step S908: The NETCONF client obtains the target node and the target value corresponding to the target node from the incremental data notification message;

[0118] Step S909: The NETCONF client updates the local value of the target node to the target value.

[0119] In the second example above, the NETCONF client sends a subscription message to the NETCONF server. This subscription message includes an incremental data indication parameter, indicating that the subscription message is used to request a subscription to the NETCONF server's incremental data. The NETCONF server returns a subscription success message to the NETCONF client, notifying it of its ability to support incremental data notification and the success of the incremental data subscription. When data changes on the NETCONF server, the target node and the corresponding target value of the target node are encapsulated into an incremental data notification message, and then the incremental data notification message is sent to the NETCONF client. After receiving the incremental data notification message, the NETCONF client obtains the target node and the corresponding target value from the incremental data notification message, and updates the local value of the target node to the target value, thereby synchronizing the data on the NETCONF server.

[0120] Please refer to FIG8 , which shows a NETCONF server provided in an embodiment of the present application. The NETCONF server 1100 includes but is not limited to:

[0121] at least one processor 1110;

[0122] at least one memory 1120, configured to store at least one program;

[0123] When the at least one program is executed by the at least one processor 1110 , the data change notification method performed by the NETCONF server as described in any of the above embodiments is executed.

[0124] It should be understood that the processor 1110 and the memory 1120 may be connected via a bus or other means.

[0125] It should be understood that the processor 1110 may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc. Alternatively, the processor 1110 may be one or more integrated circuits for executing relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0126] Memory 1120, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs, such as the data change notification method performed by the NETCONF server described in any embodiment of this application. Processor 1110 implements the data change notification method performed by the NETCONF server by executing the non-transitory software program and instructions stored in memory 1120.

[0127] The memory 1120 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and application programs required for at least one function; the data storage area may store and execute the data change notification method executed by the NETCONF server. In addition, the memory 1120 may include a high-speed random access memory and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 1120 may optionally include a memory remotely located relative to the processor 1110, and these remote memories may be connected to the processor 1110 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0128] The non-transient software programs and instructions required to implement the above-mentioned data change notification method are stored in the memory 1120. When executed by one or more processors 1110, the data change notification method performed by the NETCONF server provided in any embodiment of the present application is executed.

[0129] FIG9 shows a NETCONF client according to an embodiment of the present application. The NETCONF client 1200 includes but is not limited to:

[0130] at least one processor 1210;

[0131] at least one memory 1220, configured to store at least one program;

[0132] When the at least one program is executed by the at least one processor 1210 , the data change notification method performed by the NETCONF client as described in any of the above embodiments is performed.

[0133] It should be understood that the processor 1210 and the memory 1220 may be connected via a bus or other means.

[0134] It should be understood that the processor 1210 can be a central processing unit (CPU). The processor can also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. Alternatively, the processor 1210 uses one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0135] Memory 1220, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer executable programs, such as the data change notification method performed by a NETCONF client as described in any embodiment of this application. Processor 1210 implements the data change notification method performed by a NETCONF client by running the non-transitory software program and instructions stored in memory 1220.

[0136] The memory 1220 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and application programs required for at least one function; the data storage area may store data for executing the data change notification method executed by the NETCONF client. In addition, the memory 1220 may include a high-speed random access memory and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 1220 may optionally include a memory remotely located relative to the processor 1210, and these remote memories may be connected to the processor 1210 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0137] The non-transient software programs and instructions required to implement the above-mentioned data change notification method performed by the NETCONF client are stored in the memory 1220. When executed by one or more processors 1210, the data change notification method performed by the NETCONF client provided in any embodiment of the present application is executed.

[0138] An embodiment of the present application also provides a computer-readable storage medium, which stores a program executable by a processor. When the program executable by the processor is executed by the processor, it is used to implement the data change notification method performed by the NETCONF server or the NETCONF client as described in any of the above embodiments.

[0139] The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media.Computer-readable media can be computer-readable signal media or computer-readable storage media.Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or components, or any combination thereof.More specific examples (non-exhaustive list) of computer-readable storage media include: electrical connections with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROMs), optical storage devices, magnetic storage devices, or any suitable combination thereof.In this document, computer-readable storage media can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it.

[0140] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0141] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0142] The computer program code for performing the operations of the present application can be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (such as through the Internet using an Internet service provider).

[0143] The above is a specific description of some embodiments of the present application, but the present application is not limited to the above embodiments. Technical personnel familiar with the art can also make various equivalent modifications or substitutions without violating the scope of the present application. These equivalent modifications or substitutions are all included in the scope defined by the present application. < / ok> < / merge> < / ok> < / merge> < / rpc> < / rpc> < / ok> < / ok> < / ok> < / merge> < / ok> < / merge> < / rpc> < / rpc> < / ok> < / ok> < / ok> < / rpc>

Claims

1. A data change notification method, the method being applied to a network configuration protocol NETCONF server, the method comprising: By performing capability negotiation with the NETCONF client, the NETCONF client is notified of its capability to support incremental data notification; In response to a data change event, determining a target node where the data change occurs and a target value corresponding to the target node; Encapsulating the target node and the target value corresponding to the target node into an incremental data notification message; Send an incremental data notification message to the NETCONF client.

2. The method according to claim 1, wherein: The performing capability negotiation with the NETCONF client to notify the NETCONF client that the NETCONF client has the capability to support incremental data notification includes: A Hello message carrying an incremental data notification capability identifier is sent to the NETCONF client, so that the NETCONF client confirms that the NETCONF server has a capability to support incremental data notification according to the incremental data notification capability identifier in the Hello message.

3. The method according to claim 2, wherein: The capability negotiation with the NETCONF client further includes: Receiving a Hello message carrying the incremental data notification capability identifier sent by the NETCONF client; Confirm, according to the incremental data notification capability identifier in the received Hello message, that the NETCONF client has a capability to support incremental data notification.

4. The method according to claim 1, wherein: The performing capability negotiation with the NETCONF client to notify the NETCONF client that the NETCONF client has the capability to support incremental data notification includes: Receiving a subscription message carrying an incremental data indication parameter sent by the NETCONF client, wherein the incremental data indication parameter is used to instruct the NETCONF client to subscribe to the incremental data notification message from the NETCONF server; A subscription success message is returned to the NETCONF client, so that the NETCONF client confirms, according to the subscription success message, that the NETCONF server has a capability of supporting incremental data notification.

5. The method according to claim 4, wherein: After receiving the subscription message sent by the NETCONF client, the method further includes: Confirm, according to the subscription message, that the NETCONF client has a capability of supporting incremental data notification.

6. The method according to claim 4, wherein: The subscription message includes a subscription creation message or a subscription modification message.

7. The method according to claim 1, wherein: The step of determining, in response to a data change event, a target node where data change occurs and a target value corresponding to the target node includes: In response to data changes on any one or more data nodes in the YANG model file, the data nodes on which the data changes occur are used as target nodes, and the data nodes on which the data changes do not occur are used as non-target nodes; The value corresponding to the target node after the data is changed is used as the target value.

8. The method according to claim 7, wherein: The data node is a leaf list node, a leaf node, a list node or a container node.

9. The method according to claim 7, wherein: The incremental data notification message does not include the non-target node.

10. The method according to claim 1, wherein: The incremental data notification message carries an incremental data notification message identifier.

11. A data change notification method, the method being applied to a network configuration protocol NETCONF client, the method comprising: By performing capability negotiation with the NETCONF server, confirming that the NETCONF server has the capability to support incremental data notification; Receiving an incremental data notification message sent by the NETCONF server, wherein the incremental data notification message includes a target node and a target value corresponding to the target node, the target node represents a data node where data change occurs in the NETCONF server, and the target value represents a value of the target node after the data change; According to the incremental data notification message, the local value of the target node is updated to the target value.

12. The method according to claim 11, wherein: The confirming, through capability negotiation with the NETCONF server, that the NETCONF server has a capability to support incremental data notification includes: Receiving a Hello message carrying an incremental data notification capability identifier sent by the NETCONF server; It is determined that the NETCONF server has a capability to support incremental data notification according to the incremental data notification capability identifier in the received Hello message.

13. The method according to claim 12, wherein: The capability negotiation with the NETCONF server also includes: Send a Hello message carrying the incremental data notification capability identifier to the NETCONF server, so that the NETCONF server determines that the NETCONF client has a capability to support incremental data notification according to the incremental data notification capability identifier in the Hello message.

14. The method according to claim 11, wherein: The confirming, through capability negotiation with the NETCONF server, that the NETCONF server has a capability to support incremental data notification includes: Sending a subscription message carrying an incremental data indication parameter to the NETCONF server, where the incremental data indication parameter is used to instruct the NETCONF client to subscribe to the incremental data notification message from the NETCONF server; Receiving a subscription success message returned by the NETCONF server according to the subscription message; It is determined, according to the subscription success message, that the NETCONF server has a capability of supporting incremental data notification.

15. The method according to claim 14, wherein: The NETCONF server confirms, according to the subscription message, that the NETCONF client has a capability of supporting incremental data notification.

16. The method according to claim 14, wherein: The subscription message includes a subscription creation message or a subscription modification message.

17. The method according to claim 11, wherein: The data node is a leaf list node, a leaf node, a list node or a container node.

18. The method according to claim 11 or 17, wherein: The incremental data notification message does not include non-target nodes, and the non-target nodes represent data nodes on which no data changes occur on the NETCONF server.

19. A network configuration protocol NETCONF server, comprising: one or more processors; A memory having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the data change notification method as described in any one of claims 1-10.

20. A network configuration protocol NETCONF client, comprising: one or more processors; A memory having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the data change notification method as described in any one of claims 11-18.

21. A computer-readable storage medium having a computer program stored thereon, wherein when the program is executed by a processor, the method for notifying a data change as claimed in any one of claims 1 to 10 is implemented, or the method for notifying a data change as claimed in any one of claims 11 to 18 is implemented.

Images