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

Abstract

The invention provides a data change notification method, a NETCONF server, a NETCONF client and a storage medium, and the data change notification method comprises the steps that capability negotiation is carried out between the NETCONF server and the NETCONF client, the NETCONF server informs the NETCONF client of the capability of supporting incremental data notification, and when a data change event occurs, the NETCONF server carries out capability negotiation between the NETCONF server and the NETCONF client. The method comprises the following steps: determining a target node with data change and a target value corresponding to the target node according to the data change information, packaging the target node and the target value corresponding to the target node into an incremental data notification message, and sending the incremental data notification message to an NETCONF client, thereby reporting a data change notification to the NETCONF client. When the incremental data notification message is packaged, only the target node with data change and the target value corresponding to the target node are packaged, so that the data volume carried by the data change notification message is reduced, and the data redundancy of the data change notification is reduced.

Description

Technical Field

[0001] 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

[0002] 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 the configuration and status information of network devices.

[0003] YANG PUSH uses the NETCONF client / server communication mode to encapsulate the data of interest to the user into notification messages and report them to the user at a fixed time or according to trigger conditions. The configuration data and status data on the device can be expressed using the YANG model. The client can use YANG to dynamically obtain the configuration data and status data on the device, and hopes to dynamically perceive changes in configuration or status data, or monitor changes in certain key data. YANG PUSH provides a mechanism to actively report the device YA NG model data to the client periodically according to the subscription conditions. The device will periodically and actively report the data that the user is interested in to the specified data receiver according to the user's subscription request message, the reporting method, and the reporting data type specified in the message.

[0004] According to the YANG PUSH protocol, once the NETCONF client subscribes to the notification of data storage changes, as long as the data in the data storage changes, the NETCONF server will report the notification message according to the "push-change-update" notification format defined in the YANG PUSH protocol. The notification message needs to identify not only the value change of the data storage node, but also the type of change since the last update. At present, the YANG PUSH protocol has the following problems: the protocol mentions the use of the "replace" operation to identify the change of object value, but if it is only a minor change, such as the value change of multiple leaf nodes under a container or list, it is necessary to report the replacement change notification of the container or list, and the notification will include multiple nodes whose data has not changed; reporting the replace change notification of the leaf node requires reporting multiple change notifications. In fact, this is unnecessary. This redundant notification data causes unnecessary waste of resources, increases the burden on the NETCONF client, and is not easy to maintain and operate the network. Summary of the invention

[0005] The 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.

[0006] In a first aspect, an embodiment of the present application provides a data change notification method, the method being applied to a network configuration protocol NETCONF server, the method comprising:

[0007] By performing capability negotiation with the NETCONF client, the NETCONF client is notified of its capability to support incremental data notification;

[0008] 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;

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

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

[0011] In a second aspect, an embodiment of the present application provides a data change notification method, the method being applied to a network configuration protocol NE TCONF client, the method comprising:

[0012] By performing capability negotiation with the NETCONF server, confirming that the NETCONF server has the capability to support incremental data notification;

[0013] 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;

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

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

[0016] one or more processors;

[0017] A memory having one or more programs stored thereon, 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.

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

[0019] one or more processors;

[0020] A memory having one or more programs stored thereon, 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.

[0021] 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.

[0022] In the embodiment of the present application, the NETCONF server and the NETCONF client perform capability negotiation, the NETCONF server informs the NETCONF client of its capability to support incremental data notification, and when a data change event occurs, determines the target node where the data change occurs and the target value corresponding to the target node, then encapsulates the target node and the target value corresponding to the target node into an incremental data notification message, and then sends the incremental data notification message to the NETCONF client, thereby reporting the data change notification to the NETCONF client. Since only the target node where the data change occurs 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, and the data redundancy of the data change notification is reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 This is a schematic diagram of a NETCONF network architecture provided by an embodiment of the present application;

[0024] Figure 2 This is a schematic diagram of the steps of a data change notification method provided by an embodiment of the present application;

[0025] Figure 3 This 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;

[0026] Figure 4 This 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;

[0027] Figure 5 This is a schematic diagram of the steps of a data change notification method provided by an embodiment of the present application;

[0028] Figure 6 This is a schematic diagram of the steps of a data change notification method provided in Example 1 of the present application;

[0029] Figure 7 This is a schematic diagram of the steps of a data change notification method provided in Example 2 of this application;

[0030] Figure 8 This is a schematic diagram of the architecture of a NETCONF server provided in an embodiment of the present application;

[0031] Fig. 9 This is a schematic diagram of the architecture of a NETCONF client provided in an embodiment of the present application. DETAILED DESCRIPTION

[0032] 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 in conjunction with the accompanying drawings.

[0033] 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 being limited to the embodiments set forth herein. On the contrary, the purpose of providing these embodiments is to make this application thorough and complete, and will enable those skilled in the art to fully understand the scope of this application.

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

[0035] The terms used herein are only used to describe specific embodiments and are not intended to limit the present application. As used herein, the singular forms "a", "an" and "the" are also 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, the presence of features, wholes, steps, operations, elements and / or components is specified, but the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or groups thereof is not excluded.

[0036] 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.

[0037] In the description of the embodiments of the present application, any embodiment or design scheme of "exemplary", "for example" or "for example" should not be understood as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary", "for example" or "for example" is intended to present related concepts in a specific way.

[0038] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. The terms "include", "comprises", "has" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

[0039] 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 technology is first given.

[0040] 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. Figure 1 , Figure 1 Schematic diagram of a NETCONF network architecture provided by an embodiment of the present application. Figure 1 As shown in the figure, 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 manage the network device. <rpc>Request, query or modify one or more specific parameter values. Receive alarms and events sent by network devices to learn the current status of managed devices. Network devices act as servers in the network to maintain information data of managed devices and respond to requests from network management devices / controllers, reporting management data to the network management devices / controllers that sent the requests. A NETCONF session is a logical connection between a network management device / controller and a network device. A network device must support at least one NETCONF session.

[0041] The information that the network management device / controller obtains from the running network devices includes configuration data and status data, and by operating the configuration data, the network device status is migrated to the user's desired status. The NETCONF protocol mainly focuses on the network management device / controller operating configuration data, and does not focus on the storage method of configuration data on network devices.

[0042] It should be noted that the network management device / controller can be called the NETCONF client, and the managed network device can be called the NETCONF server. The NETCONF client must successfully establish a secure, connection-oriented session with the server to communicate. The NETCONF client sends an RPC request to the NETCONF server. After the NETCONF server processes the user request, it sends a response message to the NETCONF client. The RPC request of the NETCONF client and the response message of the NETCONF server are all encoded in XML.

[0043] 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 clearly defines the data structure and its constraints, allowing for more flexible and complete data descriptions.

[0044] 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 the notification mechanism. Different from the "send-receive" mechanism of RPC messages, which relies on the client to query data, NETCONF Notification is when an alarm or event occurs, the server actively reports it to the client through a Notification message. It is mainly used in scenarios that require real-time perception of device conditions, such as reporting alarms and events to the network management through the NETCONF protocol.

[0045] YANG PUSH uses the NETCONF client / server communication mode to encapsulate the data of interest to the user into Notifications and report them to the user at a fixed time or according to trigger conditions. The configuration data and status data on the device can be expressed using the YANG model. The client can use YANG to dynamically obtain the configuration data and status data on the device, and hopes to dynamically perceive changes in configuration or status data, or monitor changes in certain key data. YANG PUSH provides a mechanism to actively report the device YANG model data to the client periodically according to the subscription conditions. The device will periodically and actively report the data that the user is interested in to the specified data receiver according to the user's subscription request message, the reporting method, and the reporting data type specified in the message.

[0046] According to the YANG PUSH protocol, once the NETCONF client subscribes to the notification of data storage changes, as long as the data in the data storage changes, the NETCONF server will report the notification message according to the "push-change-update" notification format defined in the YANG PUSH protocol. The notification message needs to identify not only the value change of the data storage node, but also the type of change since the last update. Currently, the YANG PUSH protocol has the following problems: the protocol mentions the use of the "replace" operation to identify the change of object value, but if it is only a minor change, such as a change in the values ​​of multiple leaf nodes under a container or list, it is necessary to report the replace change notification of the container or list, and the notification will contain multiple nodes whose data has not changed; reporting the replace change notification of the leaf node requires reporting multiple change notifications, which has the problem of data redundancy. For example, a list node contains N non-critical leaf nodes, N is greater than 1, and the values ​​of M non-critical leaf nodes change, 0<M<N. According to the current standard protocol, the NETCONF server needs to report M notifications, each notification reporting a changed leaf node and its corresponding value. Or the NETCONF server reports a notification, in which N leaf nodes and their corresponding values ​​are reported, and the N nodes include changed nodes and unchanged nodes. The above method has redundant notification data, resulting in unnecessary waste of resources, increasing the burden on the NETCONF client, and is not easy to maintain and operate the network.

[0047] In view of this, an embodiment of the present application provides 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.

[0048] In the embodiment of the present application, the NETCONF server and the NETCONF client perform capability negotiation, the NETCONF server informs the NETCONF client of its capability to support incremental data notification, and when a data change event occurs, determines the target node where the data change occurs and the target value corresponding to the target node, then encapsulates the target node and the target value corresponding to the target node into an incremental data notification message, and then sends the incremental data notification message to the NETCONF client, thereby reporting the data change notification to the NETCONF client. Since only the target node where the data change occurs 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, and the data redundancy of the data change notification is reduced.

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

[0050] See also Figure 2 , Figure 2 1 is a schematic diagram of the steps of a data change notification method provided in an embodiment of the present application, and the execution subject of the method is a NETCONF server. Figure 2 As shown, the data change notification method includes the following steps S110-S140, and each step is introduced in turn below:

[0051] 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.

[0052] 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 actively reports the incremental data of the data change to the NETCONF client.

[0053] In a possible implementation, the NETCONF server performs capability negotiation with the NETCONF client and notifies the NETCONF client that it has the ability to support incremental data notification, which specifically includes 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.

[0054] It can be understood that the NETCONF server sends a Hello message to the NETCONF client, and the Hello message carries the capability identifier of the capability 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.

[0055] 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 and carrying 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.

[0056] See also Figure 3 , Figure 3 1 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. Figure 3 As shown in the figure, after the NETCONF server and the NETCONF client establish a NETCONF session, they send Hello messages to each other to announce their supported capability sets. 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 side, the NETCONF server actively reports the incremental data of the data change to the NETCONF client.

[0057] In another possible implementation, the NETCONF server performs capability negotiation with the NETCONF client and notifies the NETCONF client that it has the ability to support incremental data notification, which 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 the incremental data notification message 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 ability to support incremental data notification according to the subscription success message.

[0058] See also Figure 4 , Figure 4 1 is a schematic diagram of a process for a NETCONF server to interact with a NETCONF client and subscribe to an incremental data notification message, provided in an embodiment of the present application. Figure 4 As shown in the figure, the NETCONF server receives the subscription message sent by the NETCONF client. The NETCONF server confirms that the subscription message represents a subscription request for the incremental data notification message according to 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 NETCONF server has the capability to support incremental data notification.

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

[0060] It can be understood that the NETCONF client will send a subscription message carrying an incremental data indication parameter to the NETCONF server only 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 successful subscription message, it triggers a data change event occurring on the server and sends an incremental data notification message to the NETCONF client.

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

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

[0063] In one embodiment, the NETCONF client sends a subscription message with a message identifier of "101" to the NETCONF server, and 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 returns a response message containing a message identifier of "101" to the NETCONF client if it has the ability to support incremental data notification. 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 a message identifier of "101" to the NETCONF client. The response message carries <rpc-error>Element, indicating that the incremental data notification message subscription creation request of the NETCONF client is rejected.

[0064] 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 receiving the subscription message, the NETCONF server returns a response message containing a message identifier of "101" to the NETCONF client if it has the capability to support incremental data notification. 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 a message identifier of "101" to the NETCONF client. The response message carries <rpc-error>The element indicates that the NETCONF client's request to modify the data change notification message to the incremental data notification message format is rejected.

[0065] Step S120: In response to the data change event, the NETCONF server determines a target node where data change occurs and a target value corresponding to the target node.

[0066] Step S130: The NETCONF server encapsulates the target node and the target value corresponding to the target node into an incremental data notification message.

[0067] After the NETCONF server reaches an agreement with the NETCONF client on the incremental data notification capability, if a data change event occurs on the server, the data node where the data change currently occurs is determined, and the data node where the data change occurs is used as the target node, and the value of the target node after the data change is used as the target value, and then the target node and the target value are encapsulated into the incremental data notification message, ignoring the data nodes whose values ​​have not changed. In other words, the incremental data notification message only carries the data nodes where the data change occurs and their changed values, and the data nodes whose values ​​have not changed are not included in the incremental data notification message.

[0068] Exemplarily, 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, including: the NETCONF server responds to the data change of any one or more data nodes in the YANG model file, takes the data node where the data change occurs as the target node, and takes the data node where the data change does not occur as the non-target node; the NETCONF server takes 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 the incremental data notification message.

[0069] Exemplarily, the data node may be a leaf-list node, a leaf node, a list node, or a container node.

[0070] 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 a notification message is reported, in which N leaf nodes and their values ​​are reported, and the N nodes include changed nodes and unchanged nodes. After optimization by 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 reduced by NM 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.

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

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

[0073] In the embodiment of the present application, the NETCONF server negotiates capabilities with the NETCONF client, notifies the NETCONF client of its ability to support incremental data notification, and when a data change event occurs, determines the target node where the data change occurs and the target value corresponding to the target node, then encapsulates the target node and the target value corresponding to the target node into an incremental data notification message, and then sends the incremental data notification message to the NETCONF client, thereby reporting the data change notification to the NETCONF client. Since only the target node where the data change occurs 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, and the data redundancy of the data change notification is reduced.

[0074] See also Figure 5 , Figure 5 1 is a schematic diagram of the steps of a data change notification method provided in an embodiment of the present application, and the execution subject of the method is a NETCONF client. Figure 5 As shown, the data change notification method includes the following steps S210-S230, and each step is introduced in turn below:

[0075] 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.

[0076] Exemplarily, 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. Exemplarily, 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 message 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 actively reports the incremental data of the data change to the NETCONF client.

[0077] In a 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, which specifically includes the following steps: the NETCONF client receives a Hello message sent by the NETCONF server and carrying 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.

[0078] Exemplarily, the process of capability negotiation between the NETCONF client and the NETCONF server may also 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 ability to support incremental data notification based on the incremental data notification capability identifier in the Hello message.

[0079] Exemplarily, after the NETCONF server and the NETCONF client establish a NETCONF session, they send Hello messages to each other to announce their respective supported capability sets. The Hello messages sent by the NETCONF server and the NETCONF client both carry an incremental data notification capability identifier, that is, the NETCONF server and the NETCONF client both support the incremental data notification capability. After confirming that the incremental data notification capability is supported by each other, the NETCONF client sends an incremental data subscription request message to the NETCONF server, and the NETCONF server returns a Hello message carrying an 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 side, the NETCONF server actively reports the incremental data of the data change to the NETCONF client.

[0080] 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, which specifically includes 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 the incremental data notification message 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 that the NETCONF server has the ability to support incremental data notification based on the subscription success message.

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

[0082] It can be understood that the NETCONF client will send a subscription message carrying an incremental data indication parameter to the NETCONF server only 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 successful subscription message, it triggers a data change event occurring on the server and sends an incremental data notification message to the NETCONF client.

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

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

[0085] In one embodiment, the NETCONF client sends a subscription message with a message identifier of "101" to the NETCONF server, and 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 returns a response message containing a message identifier of "101" to the NETCONF client if it has the ability to support incremental data notification. 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 a message identifier of "101" to the NETCONF client. The response message carries <rpc-error>Element, indicating that the incremental data notification message subscription creation request of the NETCONF client is rejected.

[0086] 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 form; after receiving the subscription message, the NETCONF server returns a response message containing a message identifier of "101" to the NETCONF client if it has the ability to support incremental data notification. 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 a message identifier of "101" to the NETCONF client. The response message carries <rpc-error>The element indicates that the NETCONF client's request to modify the data change notification message to the incremental data notification message format is rejected.

[0087] Step S220, the NETCONF client receives the 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.

[0088] Step S230: The NETCONF client updates the local value of the target node to the target value according to the incremental data notification message.

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

[0090] Exemplarily, 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.

[0091] Exemplarily, in response to data changes in any one or more data nodes in the YANG model file, the NETCONF server uses the data nodes with data changes as target nodes and the data nodes without data changes as non-target nodes; the NETCONF server uses 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, 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, that is, the target node and the corresponding target value, from the incremental data notification message, and then locally updates the value corresponding to the target node to the target value, thereby achieving the purpose of synchronously updating the data of the NETCONF server.

[0092] The technical solution of the embodiment of the present application is described in detail below through specific examples.

[0093] Example 1:

[0094] See also Figure 6 , Figure 6 This is a schematic diagram of a data change notification method provided in Example 1 of the present application, the method comprising the following steps:

[0095] Step S801: The NETCONF client sends a hello message 1 to the NETCONF server. The hello message 1 carries the capability set of the NETCONF client to notify the NETCONF server of its supported capabilities. The capability set contains an incremental data notification capability identifier. The NETCONF client confirms that the NETCONF server has the capability to support incremental data notification according to the incremental data notification capability identifier.

[0096] Step S802: The NETCONF server sends a hello message 2 to the NETCONF client. The hello message 2 carries the capability set of the NETCONF server to notify the NETCONF client of its supported capabilities. The capability set contains an incremental data notification capability identifier. The NETCONF server confirms that the NETCONF client has the capability to support incremental data notification according to the incremental data notification capability identifier.

[0097] Step S803, the NETCONF client subscribes to the incremental data notification from the NETCONF server;

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

[0099] Step S805, 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 occurring on the server;

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

[0101] Step S807: The NETCONF server sends an incremental data notification message to the NETCONF client, where the incremental data notification message carries an incremental data notification message identifier; correspondingly, the NETCONF client receives the message from the NETCONF server, and determines that the message is an incremental data notification message according to the incremental data notification message identifier carried in the message;

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

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

[0104] In the above example 1, the NETCONF client and the NETCONF server send hello messages to each other and exchange their supported capabilities to confirm that both parties have the ability to support incremental data notification. Then, when data changes occur on the NETCONF server, the target node with data changes and the target value corresponding to 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 target value corresponding to the target node from the incremental data notification message, and updates the local value of the target node to the target value, thereby achieving the purpose of synchronously updating the data on the NETCONF server.

[0105] Example 2:

[0106] See also Figure 7 , Figure 7 This is a schematic diagram of a data change notification method provided in Example 2 of the present application, the method comprising the following steps:

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

[0108] Step S902: The NETCONF server receives a subscription message from the NETCONF client, confirms that the NETCONF client subscribes to the incremental data notification according to the incremental data indication parameter in the subscription message, and returns a subscription success message to the NETCONF client.

[0109] Step S903, the NETCONF client receives a subscription success message from the NETCONF server, and confirms, according to the subscription success message, that the NETCONF server has the capability to support incremental data notification;

[0110] Step S904, 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 occurring on the server;

[0111] Step S905: The NETCONF server ignores the data nodes where no data change has occurred, and encapsulates the target node and the target value corresponding to the target node into an incremental data notification message;

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

[0113] Step S907: The NETCONF client receives the message from the NETCONF server, and determines that the message is an incremental data notification message according to the incremental data notification message identifier carried in the message;

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

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

[0116] In the above example 2, the NETCONF client sends a subscription message to the NETCONF server, and the subscription message includes an incremental data indication parameter, indicating that the subscription message is used to request to subscribe to the incremental data of the NETCONF server; the NETCONF server returns a subscription success message to the NETCONF client to notify the NETCONF client that it has the ability to support incremental data notification and that the incremental data subscription is successful; when data changes occur on the NETCONF server, the target node with data changes and the target value corresponding to 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 target value corresponding to the target node from the incremental data notification message, and updates the local value of the target node to the target value, thereby achieving the purpose of synchronously updating the data of the NETCONF server.

[0117] See also Figure 8 , is a NETCONF server provided in an embodiment of the present application. The NETCONF server 1100 includes but is not limited to:

[0118] at least one processor 1110;

[0119] At least one memory 1120, used to store at least one program;

[0120] When at least one program is executed by 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.

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

[0122] 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 gates 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 related programs to implement the technical solutions provided in the embodiments of the present application.

[0123] The 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 the present application. The processor 1110 implements the data change notification method performed by the NETCONF server by running the non-transitory software program and instructions stored in the memory 1120.

[0124] 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 disposed 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.

[0125] 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.

[0126] See also Fig. 9 , is a NETCONF client provided in an embodiment of the present application, and the NETCONF client 1200 includes but is not limited to:

[0127] at least one processor 1210;

[0128] At least one memory 1220, used to store at least one program;

[0129] 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.

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

[0131] It should be understood that the processor 1210 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 gates 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 1210 may be one or more integrated circuits for executing related programs to implement the technical solutions provided in the embodiments of the present application.

[0132] The 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 the NETCONF client described in any embodiment of the present application. The processor 1210 implements the data change notification method performed by the NETCONF client by running the non-transitory software program and instructions stored in the memory 1220.

[0133] 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 and execute 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 disposed 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.

[0134] 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.

[0135] 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.

[0136] 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 devices, or any combination of the above. More specific examples (non-exhaustive lists) 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-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. 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.

[0137] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0138] The program code embodied on the 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.

[0139] Computer program code for performing the operations of the present application may 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 may 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 the case of a remote computer, the remote computer may 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 may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0140] The above is a specific description of the preferred implementation of the present application, but the present application is not limited to the above-mentioned implementation mode. Technical personnel familiar with the field can also make various equivalent modifications or substitutions without violating the spirit 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, characterized in that: 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, characterized in that The capability negotiation with the NETCONF client further includes: Receiving a Hello message sent by the NETCONF client and carrying the incremental data notification capability identifier; 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, characterized in that 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, characterized in that 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, characterized in that The subscription message includes a subscription creation message or a subscription modification message.

7. The method according to claim 1, characterized in that 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, characterized in that 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, characterized in that: The incremental data notification message does not include the non-target node.

10. The method according to claim 1, characterized in that 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, characterized in that 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; Determine, according to the incremental data notification capability identifier in the received Hello message, whether the NETCONF server has the capability to support incremental data notification.

13. The method according to claim 12, characterized in that The capability negotiation with the NETCONF server also includes: Sending 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, characterized in that 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; Determine, according to the subscription success message, whether the NETCONF server has the capability of supporting incremental data notification.

15. The method according to claim 14, characterized in that 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, characterized in that The subscription message includes a subscription creation message or a subscription modification message.

17. The method according to claim 11, characterized in that 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, characterized in that 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