A single-process embedded NETCONF configuration management method, system and terminal

Abstract

The application belongs to the technical field of communication network and routing control plane configuration management, and relates to a single-process embedded NETCONF configuration management method, system and terminal. The management method comprises the following steps: embedding a NETCONF server module and a YANG data tree in a routing control plane management process, creating a data storage instance; initializing the NETCONF server module and making it enter a listening state; after a session is established with a NETCONF client, receiving an RPC request in the process by the NETCONF server module, parsing an XML message to extract an operation type, configuration change data of the NETCONF and a target path; calling the data storage instance by the NETCONF server module through an interface in the routing control plane management process; and performing corresponding configuration transaction operations on a candidate configuration library and / or a running configuration library according to the operation type by the data storage instance. The application significantly reduces the system integration and operation complexity and guarantees the strong consistency of multi-interface configuration.

Description

Technical Field

[0001] This invention relates to the field of communication network and routing control plane configuration management technology, and in particular to a single-process embedded NETCONF configuration management method, system and terminal. Background Technology

[0002] Existing routing control planes typically need to support multiple southbound configuration interfaces simultaneously, including the Command Line Interface (CLI), Network Configuration Protocol (NETCONF), and YANG data. Typical implementations (such as libnetopeer and sysrepo) often employ an external YANG storage management model and configuration data, then use inter-process communication and routing protocol stack interaction to achieve configuration synchronization and distribution.

[0003] This type of architecture has the following shortcomings in engineering implementation: First, it has high dependency and integration costs. This type of architecture requires separate deployment and maintenance of external NETCONF service libraries and external YANG data storage libraries (such as libnetopeer and sysrepo), and decoupling from the routing protocol stack, increasing the system integration, deployment and maintenance costs, and making it difficult to adapt to highly integrated network operating systems and embedded network devices. Second, there are risks of dual-source configuration and consistency. External configuration libraries and internal configuration representations of the protocol stack coexist. When operating in parallel through interfaces such as NETCONF and CLI, it may lead to inconsistent configuration coverage and states. Third, the implementation of transaction semantics is limited. Transaction links such as candidate / run require cross-process forwarding and synchronization, and commit confirmation and consistency maintenance are performed between external storage and the protocol stack, increasing latency and failure rollback costs, making it difficult to form a single-process candidate / commit / rollback control closed loop. Fourth, it is difficult to form an end-to-end control link. The configuration control logic is scattered in multiple processes and components, and it is difficult to achieve a unified control plane configuration capability in a closed loop in a single execution link.

[0004] Given the above shortcomings, there is an urgent need to propose a new architecture that can integrate the NETCONF server and YANG data management capabilities into the routing control plane process and build a unified configuration control plane without sacrificing NETCONF / YANG standard compatibility. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by proposing a single-process embedded NETCONF configuration management method, system, and terminal. By embedding the NETCONF server and YANG data management capabilities within the routing control plane management process, it avoids the architectural complexity caused by external NETCONF service libraries, external YANG data storage libraries, and inter-process collaboration. Furthermore, this invention aggregates configurations from all sources into a single data storage instance within the same process, effectively eliminating the risks of dual-source configurations and state drift. In addition, this invention uses intra-process calls instead of inter-process communication, effectively reducing the overhead of serialization / deserialization and inter-process communication (IPC).

[0006] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides a single-process embedded NETCONF configuration management method, comprising the following steps: S1. Start the routing control plane management process, load and parse the YANG model file, and build the YANG data tree; S2. Create a data storage instance within the routing control plane management process. The data storage instance includes at least a runtime configuration library and a candidate configuration library. Each data storage instance corresponds to an independent YANG data tree. Initialize the NETCONF server module and put it into listening state. S3. After establishing a session with the NETCONF client, the NETCONF server module receives RPC requests within the routing control plane management process, parses XML messages to extract the operation type, NETCONF configuration change data, and target path; The S4.NETCONF server module calls the data storage instance through the interface within the routing control plane management process to read and write configuration change data based on the operation type. S5. When the operation type is an edit configuration operation, write the configuration change data to the candidate configuration library; when the operation type is a submit operation, merge or switch the configuration change data in the candidate configuration library to the running configuration library, notify the routing protocol stack through the in-process interface, and the routing protocol stack reads the configuration change data from the running configuration library and applies it; when the operation type is a rollback operation, discard the configuration change data in the candidate configuration library and keep the running configuration library unchanged.

[0007] As one possible implementation, before writing the configuration change data into the candidate configuration library, the configuration change data is validated based on the YANG data tree corresponding to the candidate configuration library. The validation includes at least: syntax validation, constraint validation, and dependency validation.

[0008] As one possible implementation, the single-process embedded NETCONF configuration management approach also includes: Within the routing control plane management process, a configuration entry adaptation layer is set up. When a configuration request is received through a non-NETCONF configuration entry, the configuration entry adaptation layer parses the configuration request to obtain the configuration command, and maps the configuration command to a standard editing operation on the data storage instance. The standard editing operation and the NETCONF configuration editing operation use the same data read / write rules and verification rules.

[0009] As one possible implementation, the non-NETCONF configuration entry point should at least include the command-line interface (CLI); the configuration entry adaptation layer should at least include NETCONF configuration functions.

[0010] As one possible implementation, the NETCONF configuration function can be obtained using the following method: The NETCONF-side processing flow and the command-line-side processing flow are modeled in a unified manner and abstracted into a common configuration processing link. Non-common processes caused only by differences in the entry protocol are semantically mapped at the configuration entry adaptation layer so that they can be incorporated into the common configuration processing link. The configuration interface functions in the common configuration processing link are extracted as NETCONF configuration functions.

[0011] As one possible implementation, configuration commands can be mapped to standard editing operations on data storage instances using the following method: The NETCONF server module parses XML messages, extracts configuration change data and target paths, and generates NETCONF standard edit requests; the command-line interface (CLI) parses configuration commands, extracts command-line configuration change data and binds it to the target path, and generates CLI standard edit requests that are isomorphic to NETCONF; both NETCONF standard edit requests and CLI standard edit requests are applied to the data storage instance according to the corresponding target path.

[0012] As one possible implementation, notifying the routing protocol stack via an in-process interface includes: invoking a pre-registered callback function by a data storage instance; and / or sending configuration change messages via inter-process event notification.

[0013] Secondly, this invention provides a single-process embedded NETCONF configuration management system, comprising: The YANG data tree construction module starts the routing control plane management process, loads and parses the YANG model file, and constructs the YANG data tree. The data storage module creates data storage instances within the routing control plane management process. Each data storage instance includes at least a runtime configuration library and a candidate configuration library, and each data storage instance corresponds to an independent YANG data tree. The NETCONF server module initializes and enters a listening state. After establishing a session with the NETCONF client, the NETCONF server module receives RPC requests within the routing control plane management process, parses XML messages to extract the operation type, NETCONF configuration change data, and target path. The NETCONF server module then calls the data storage instance through the interface within the routing control plane management process to read and write the configuration change data based on the operation type. The transaction commit module, when the operation type is an edit configuration operation, writes the configuration change data to the candidate configuration library. Before writing the configuration change data to the candidate configuration library, it verifies the configuration change data based on the YANG data tree corresponding to the candidate configuration library. The verification includes at least: syntax verification, constraint verification, and dependency verification. When the operation type is a commit operation, the configuration change data in the candidate configuration library is merged or switched to the running configuration library. The routing protocol stack is notified through an in-process interface, and the routing protocol stack reads the configuration change data from the running configuration library and applies it. When the operation type is a rollback operation, the configuration change data in the candidate configuration library is discarded, and the running configuration library remains unchanged.

[0014] As one possible implementation, a single-process embedded NETCONF configuration management system also includes: The configuration entry adaptation module sets up a configuration entry adaptation layer within the routing control plane management process. When a configuration request is received through a non-NETCONF configuration entry, the configuration entry adaptation layer parses the configuration request to obtain the configuration command and maps the configuration command to a standard editing operation on the data storage instance. The standard editing operation and the NETCONF configuration editing operation use the same data read / write rules and verification rules.

[0015] Thirdly, the present invention provides a terminal including a processor and a communication interface coupled to the processor, the processor being used to run computer programs or instructions to implement the single-process embedded NETCONF configuration management method provided in the first aspect of the claim.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. The single-process embedded NETCONF configuration management method, system, and terminal proposed in this invention embed the NETCONF server module and YANG data storage capabilities within the routing control plane management process, replacing the traditional distributed architecture of "external NETCONF service library + external YANG data storage library + inter-process collaboration". All configuration management-related logic (session management, RPC parsing, data verification, candidate / runtime library maintenance, configuration activation notification) is completed within a single process space, forming a unified configuration control plane, significantly reducing system integration and maintenance complexity.

[0017] 2. The single-process embedded NETCONF configuration management method, system, and terminal proposed in this invention, by setting up a configuration entry adaptation layer, parses and converts commands from non-NETCONF configuration entry points such as CLI into standard editing operations on the same YANG data tree, reusing the same set of data storage, verification logic, and activation paths as NETCONF. NETCONF and CLI write from the same source, read from the same view, and distribute to the same path, fundamentally eliminating the risks of configuration overwriting and state drift, and ensuring strong consistency of multi-interface configurations.

[0018] 3. The single-process embedded NETCONF configuration management method, system, and terminal proposed in this invention independently maintain a candidate configuration library and a running configuration library within the routing control plane management process. By writing candidates, applying them to runtime and triggering protocol stack updates, and rolling back and abandoning changes, it fully implements the transactional configuration management of the NETCONF standard without the need for cross-process coordination. This single-process closed-loop mechanism avoids the complexity and failure rollback risks of cross-process two-phase commits in traditional solutions.

[0019] 4. Because the NETCONF server module and data storage module run in the same process space, all RPC parsing, data verification, and configuration reading and writing are completed through in-process function calls, eliminating the need for serialization / deserialization and context switching overhead associated with inter-process communication (IPC). Compared to solutions that rely on external components (such as sysrepo + libnetopeer), the end-to-end latency of configuration distribution is significantly reduced, and CPU and memory resource consumption is lower, making it particularly suitable for resource-constrained embedded network devices.

[0020] 5. In this invention, the NETCONF server embedded in the routing control plane management process supports standard configuration verification, confirmation submission, and rollback mechanisms. Configuration changes can undergo complete YANG model verification (syntax, constraints, dependencies) before submission, preventing erroneous configurations from entering the running state. Confirmation submission allows for automatic rollback if no confirmation is received within a specified time, effectively reducing the impact of human error on network stability and providing a secure and reliable configuration management foundation for frequent adjustments to routing policies within the autonomous system. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a flowchart of the single-process embedded NETCONF configuration management method proposed in an embodiment of the present invention. Detailed Implementation

[0022] To facilitate a clear description of the technical solutions in the embodiments of the present invention, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. For example, the first threshold and the second threshold are merely used to distinguish different thresholds and do not limit their order. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" are not necessarily different.

[0023] It should be noted that in this invention, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in this invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0024] In this invention, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one" or similar expressions refer to any combination of these items, including any combination of singular or plural items. For example, "at least one of a, b, or c" can represent: a, b, c, a combination of a and b, a combination of a and c, a combination of b and c, or a, b, and c, where a, b, and c can be single or multiple.

[0025] This invention aims to provide a single-process embedded NETCONF configuration management method, system, and terminal. By embedding the NETCONF server and YANG data management capabilities within the routing control plane management process, it avoids the architectural complexity caused by external NETCONF service libraries, external YANG data storage libraries, and inter-process collaboration. Furthermore, this invention aggregates configurations from all sources into a single data storage instance within the same process, effectively eliminating the risks of dual-source configurations and state drift. In addition, this invention effectively reduces serialization / deserialization and IPC overhead by replacing inter-process communication with intra-process calls.

[0026] Firstly, embodiments of the present invention provide a single-process embedded NETCONF configuration management method, see [link to relevant documentation]. Figure 1 It includes the following steps: S1. Start the routing control plane management process, load and parse the YANG model file, and build the YANG data tree; As an example, the YANG model file is loaded and parsed to construct the YANG data tree using the following method: / / Define the YANG model file to be launched static const struct frr_yang_module_info const mgmt_yang_modules[] ={ &frr_filter_info, &frr_interface_info, &frr_route_map_info, &frr_routing_info, &frr_vrf_info, ............ }; FRR_DAEMON_INFO(mgmtd, MGMTD, ............ .yang_modules = mgmt_yang_modules, .n_yang_modules = array_size(mgmt_yang_modules), ............ ); / / The frr_init function is called when mgmt starts. int main(int argc, char argv) { ............ mgmt_master_init(frr_init(), buffer_size); ............ mgmt_init(); ............ } / / The frr_init function loads the YANG model file to be started. struct event_loop frr_init(void) { ............ while (modules) { modules = (oc = modules)->next; module = frrmod_load(oc->arg, dir, _err_print, __func__); if (!module) exit(1); XFREE(MTYPE_TMP, oc); } ............ } This invention embeds the NETCONF server module and YANG data storage capabilities within the routing control plane management process, replacing the traditional distributed architecture of "external NETCONF service library + external YANG data storage library + inter-process collaboration". All configuration management-related logic (session management, RPC parsing, data verification, candidate / runtime library maintenance, configuration activation notification) is completed within a single process space, forming a unified configuration control plane, significantly reducing system integration and maintenance complexity.

[0027] S2. Create a data storage instance within the routing control plane management process. The data storage instance includes at least a runtime configuration library and a candidate configuration library. Each data storage instance corresponds to an independent YANG data tree. Initialize the NETCONF server module and put it into listening state. As an example, the following method is used to create a data storage instance within the routing control plane management process, initialize the NETCONF server module, and put it into a listening state: / / Initialize mgmt void mgmt_init(void) { ............ / Initialize datastores / mgmt_ds_init(mm); ............ mgmt_netconf_server_init(mm); ............ } / / Create a data storage instance: Initialize the running configuration library and candidate configuration libraries int mgmt_ds_init(struct mgmt_master mm) { ............ running.root.cfg_root = running_config; running.config_ds = true; running.ds_id = MGMTD_DS_RUNNING; candidate.root.cfg_root = nb_config_dup(running.root.cfg_root); candidate.config_ds = true; candidate.ds_id = MGMTD_DS_CANDIDATE; ............ mm->running_ds =&running; mm->candidate_ds =&candidate; mm->oper_ds =&oper; ............ } / / Initialize the NETCONF server module and make it enter the listening state int mgmt_netconf_server_init(struct mgmt_master mm) { ............ #ifdef HAVE_NETCONF_SERVER if (!netconf_cfg.enable) { return 0; } if (mgmt_netconf_server_apply_cfg() != 0) { zlog_err("%s: NETCONF server initialization failed", NETCONF_LOG_PREFIX); return -1; } / Start polling timer for accept / poll loop / event_add_timer_msec(netconf_master, mgmt_netconf_poll_timer_cb,NULL, 50,&netconf_poll_timer); #endif / HAVE_NETCONF_SERVER / ............ } This invention independently maintains a candidate configuration library and a runtime configuration library within the routing control plane management process. By writing to candidates, applying the changes to runtime and triggering protocol stack updates, and then rolling back and abandoning the changes, it fully implements the transactional configuration management of the NETCONF standard without the need for cross-process coordination. This single-process closed-loop mechanism avoids the complexity and failure rollback risks of cross-process two-phase commits in traditional solutions.

[0028] S3. After establishing a session with the NETCONF client, the NETCONF server module receives RPC requests within the routing control plane management process, parses XML messages to extract the operation type, NETCONF configuration change data, and target path; As an example, the following method is used to receive RPC requests and parse XML messages: / / Receive RPC requests, extract operation types, and dispatch them for processing. static struct nc_server_reply mgmt_netconf_rpc_cb(struct lyd_node rpc, struct nc_session session) { ............ rpc_name = LYD_NAME(rpc); ............ / Process different RPC operations / if (!strcmp(rpc_name, "get-config")) { reply = mgmt_netconf_get_config(rpc, session); ............ return reply; } else if (!strcmp(rpc_name, "edit-config")) { ............ reply = mgmt_netconf_edit_config(rpc, session); ............ } / / Configuration change processing static struct nc_server_reply mgmt_netconf_edit_config(struct lyd_node rpc, struct nc_session session) { ............ if (mgmt_netconf_parse_target(rpc, session_ctx,&reply) != 0) { ............ } ............ } / / Parse XML message static int mgmt_netconf_parse_target(struct lyd_node rpc, const struct ly_ctx session_ctx, struct nc_server_reply pReply) { ............ if (lyd_find_path(rpc, "target", 0,&target_node)) { ............ return -1; } ............ if (strcmp(target_ds, "running")) { err_node = nc_err(session_ctx, NC_ERR_OP_NOT_SUPPORTED, NC_ERR_TYPE_PROT); nc_err_set_msg(err_node, "Only 'running' datastore is supported for edit-config", "en"); ............ } The S4.NETCONF server module calls the data storage instance through the interface within the routing control plane management process to read and write configuration change data based on the operation type. S5. When the operation type is an edit configuration operation, write the configuration change data to the candidate configuration library; when the operation type is a submit operation, merge or switch the configuration change data in the candidate configuration library to the running configuration library, notify the routing protocol stack through the in-process interface, and the routing protocol stack reads the configuration change data from the running configuration library and applies it; when the operation type is a rollback operation, discard the configuration change data in the candidate configuration library and keep the running configuration library unchanged.

[0029] As an example, when the operation type is an edit configuration operation, the following method is used to write the configuration change data to the candidate configuration library: / / When the operation type is "edit configuration", perform configuration change processing. static struct nc_server_reply mgmt_netconf_edit_config(struct lyd_node rpc, struct nc_session session) { ............ ds_ctx = mgmt_ds_get_ctx_by_id(mm, MGMTD_DS_RUNNING); ............ running_cfg = mgmt_ds_get_nb_config(ds_ctx); ............ candidate = nb_config_dup(running_cfg); ............ config_data_root = mgmt_netconf_parse_config(rpc, session_ctx,&reply); ............ native_config_tree = mgmt_netconf_duplicate_config_tree(config_data_root, session_ctx, &reply); ............ nb_ret = nb_candidate_commit_prepare(context, candidate, NULL, &transaction, false, false, errmsg, sizeof(errmsg)); ............ mgmt_netconf_forward_config(session, candidate); ............ reply = nc_server_reply_ok(); return mgmt_netconf_edit_finish(reply); } As an example, when the operation type is a commit operation, the following method is used to merge or switch the configuration change data in the candidate configuration repository to the running configuration repository: / / Transaction preparation: The editing process connects the candidate configuration library and the runtime configuration library. Edit-config configuration changes are synchronized to the candidate database, and transaction processing is triggered. static void mgmt_netconf_forward_config(struct nc_session session, struct nb_config candidate) { ............ / Create configuration transaction ID / txn_id = mgmt_create_txn(mgmt_sess->session_id, MGMTD_TXN_TYPE_CONFIG); ............ candidate_ds_ctx = mgmt_ds_get_ctx_by_id(mm,MGMTD_DS_CANDIDATE); running_ds_ctx = mgmt_ds_get_ctx_by_id(mm, MGMTD_DS_RUNNING); ............ candidate_ds_config = mgmt_ds_get_nb_config(candidate_ds_ctx); running_ds_config = mgmt_ds_get_nb_config(running_ds_ctx); ............ if (mgmt_txn_send_commit_config_req(txn_id, 0, MGMTD_DS_CANDIDATE, candidate_ds_ctx, MGMTD_DS_RUNNING, running_ds_ctx, false, false, false, edit_req) != 0) { ............ mgmt_destroy_txn(&txn_id); return; } ............ } / / Submit a configuration change request (a change request from candidate library to runtime library) to the transaction system. int mgmt_txn_send_commit_config_req(uint64_t txn_id, uint64_t req_id, Mgmtd__DatastoreId src_ds_id, struct mgmt_ds_ctx src_ds_ctx, Mgmtd__DatastoreId dst_ds_id, struct mgmt_ds_ctx dst_ds_ctx, bool validate_only, bool abort, bool implicit, struct mgmt_edit_req edit) { ............ txn_req->req.commit_cfg.src_ds_id = src_ds_id; txn_req->req.commit_cfg.src_ds_ctx = src_ds_ctx; txn_req->req.commit_cfg.dst_ds_id = dst_ds_id; txn_req->req.commit_cfg.dst_ds_ctx = dst_ds_ctx; ............ mgmt_txn_register_event(txn, MGMTD_TXN_PROC_COMMITCFG); return 0; } / / Transaction processing flow: Configuration change data in the candidate configuration repository is merged into the running configuration repository. static int mgmt_txn_send_commit_cfg_reply(struct mgmt_txn_ctx txn, enum mgmt_result result, const char error_if_any) { ............ if (success) { ............ if (txn->session_id&&txn->commit_cfg_req->req.commit_cfg.abort) { mgmt_ds_copy_dss(txn->commit_cfg_req->req.commit_cfg.dst_ds_ctx, txn->commit_cfg_req->req.commit_cfg.src_ds_ctx, false); } } else { if (txn->commit_cfg_req->req.commit_cfg.implicit) mgmt_ds_copy_dss(txn->commit_cfg_req->req.commit_cfg.dst_ds_ctx, txn->commit_cfg_req->req.commit_cfg.src_ds_ctx, false); } ............ if (txn->commit_cfg_req->req.commit_cfg.rollback) { mgmt_ds_unlock(txn->commit_cfg_req->req.commit_cfg.src_ds_ctx); mgmt_ds_unlock(txn->commit_cfg_req->req.commit_cfg.dst_ds_ctx); ............ mgmt_history_rollback_complete(success); } ............ } As one possible implementation, before writing the configuration change data into the candidate configuration library, the configuration change data is validated based on the YANG data tree corresponding to the candidate configuration library. The validation includes at least: syntax validation, constraint validation, and dependency validation.

[0030] As one possible implementation, the single-process embedded NETCONF configuration management approach also includes: Within the routing control plane management process, a configuration entry adaptation layer is set up. When a configuration request is received through a non-NETCONF configuration entry, the configuration entry adaptation layer parses the configuration request to obtain the configuration command, and maps the configuration command to a standard editing operation on the data storage instance. The standard editing operation and the NETCONF configuration editing operation use the same data read / write rules and verification rules.

[0031] In this invention, the NETCONF server embedded in the routing control plane management process supports standard configuration verification, confirmation submission, and rollback mechanisms. Configuration changes undergo complete YANG model verification (syntax, constraints, dependencies) before submission, preventing erroneous configurations from entering the running state. Confirmation submission allows for automatic rollback if no confirmation is received within a specified time, effectively reducing the impact of human error on network stability and providing a secure and reliable configuration management foundation for frequent adjustments to routing policies within the autonomous system. As one possible implementation, the non-NETCONF configuration entry point should at least include the command-line interface (CLI); the configuration entry adaptation layer should at least include NETCONF configuration functions.

[0032] As one possible implementation, the NETCONF configuration function can be obtained using the following method: The NETCONF-side processing flow and the command-line-side processing flow are modeled in a unified manner and abstracted into a common configuration processing link. Non-common processes caused only by differences in the entry protocol are semantically mapped at the configuration entry adaptation layer so that they can be incorporated into the common configuration processing link. The configuration interface functions in the common configuration processing link are extracted as NETCONF configuration functions.

[0033] As one possible implementation, configuration commands can be mapped to standard editing operations on data storage instances using the following method: The NETCONF server module parses XML messages, extracts configuration change data and target paths, and generates NETCONF standard edit requests; the command-line interface (CLI) parses configuration commands, extracts command-line configuration change data and binds it to the target path, and generates CLI standard edit requests that are isomorphic to NETCONF; both NETCONF standard edit requests and CLI standard edit requests are applied to the data storage instance according to the corresponding target path.

[0034] This invention establishes a configuration entry adaptation layer to parse and convert commands from non-NETCONF configuration entry points such as CLI into standard editing operations on the same YANG data tree, reusing the same data storage, verification logic, and application path as NETCONF. NETCONF and CLI write from the same source, read from the same view, and distribute to the same path, fundamentally eliminating the risks of configuration overwriting and state drift, and ensuring strong consistency across multiple interface configurations.

[0035] As one possible implementation, notifying the routing protocol stack via an in-process interface includes: invoking a pre-registered callback function by a data storage instance; and / or sending configuration change messages via inter-process event notification.

[0036] The technical solution of the present invention will be further illustrated below using a specific network configuration as an example.

[0037] Suppose we have a router based on Free Range Routing (FRR) that needs to be configured with a Border Gateway Protocol (BGP) neighbor with the IP address 100.100.100.1. This invention will distribute this configuration via the embedded NETCONF, and it can also be modified subsequently via the CLI. The specific implementation process is as follows: The first step is to start the routing control plane management process (Management Daemon, mgmtd), load and parse the BGP YANG model file (Yet Another Next Generation), and build two initially empty YANG data trees: candidate and running.

[0038] The second step involves creating a runtime configuration repository and a candidate configuration repository within mgmtd. The runtime configuration repository corresponds to the running data tree, and the candidate configuration repository corresponds to the candidate data tree. The NETCONF server is then initialized and bound to mgmtd's transport layer (e.g., the SSH netconf subsystem), and the NETCONF server enters a listening state.

[0039] Third, the client establishes a session with the router through NETCONF. The NETCONF server directly completes the hello negotiation and capability exchange within mgmtd. The NETCONF server receives the get-config request, parses the XML message in the process, and extracts the operation type edit-config, the NETCONF configuration change data "bgp:...", and the target path candidate.

[0040] The fourth step is to verify whether the XML message format conforms to the YANG model. If it does, the `candidate` function is called within the process. A node is created in `candidate`, and BGP neighbor child nodes are written. The NETCONF server encapsulates the returned result into an RPC response and sends it to the client. At this point, `running` is still empty, and the `mgmtd` process is completely unaware of this configuration. This entire process is completed within the process itself, without needing to call external sysrepo or other independent processes.

[0041] The fifth step involves merging the changes in the candidate data into the running data tree upon receiving a commit or equivalent commit operation. At this point, the running data tree contains the BGP neighbor IP address: 100.100.100.1. The mgmtd process detects that a node has been created / modified, immediately searches for the callback function registered on that path, and notifies the routing protocol stack via an in-process interface. The routing protocol stack then reads the changes from the running data tree and applies them. Throughout the commit process, mgmtd internally handles the merging of the candidate data into the running data tree, notifying bgpd only once via a lightweight IPC. This eliminates the need for intermediate processes like sysrepo in traditional solutions, significantly reducing latency and resource consumption.

[0042] Step 6: Assuming modifications need to be made via CLI, traditional methods, when operating in parallel through interfaces such as NETCONF and CLI, may lead to inconsistencies in configuration overwriting and state. This solution transforms CLI configuration commands into equivalent YANG data tree operations. Configurations written via either NETCONF or CLI are stored in the same running data tree and sent to bgpd through the same callback mechanism.

[0043] By setting up a configuration entry adaptation layer, this invention parses and converts commands from non-NETCONF configuration entry points such as CLI into standard editing operations on the same YANG data tree, thus integrating with NETCONF's... <edit-config>By reusing the same set of data storage, verification logic, and activation paths, the risks of configuration overwriting and state drift are fundamentally eliminated, ensuring strong consistency of configurations across multiple interfaces.

[0044] Secondly, this invention provides a single-process embedded NETCONF configuration management system, comprising: The YANG data tree construction module starts the routing control plane management process, loads and parses the YANG model file, and constructs the YANG data tree. The data storage module creates data storage instances within the routing control plane management process. Each data storage instance includes at least a runtime configuration library and a candidate configuration library, and each data storage instance corresponds to an independent YANG data tree. The NETCONF server module initializes and enters a listening state. After establishing a session with the NETCONF client, the NETCONF server module receives RPC requests within the routing control plane management process, parses XML messages to extract the operation type, NETCONF configuration change data, and target path. The NETCONF server module then calls the data storage instance through the interface within the routing control plane management process to read and write the configuration change data based on the operation type. In the transaction commit module, when the operation type is an edit configuration operation, the configuration change data is written to the candidate configuration library. Before writing the configuration change data to the candidate configuration library, the configuration change data is validated based on the YANG data tree corresponding to the candidate configuration library. The validation includes at least: syntax validation, constraint validation, and dependency validation. When the operation type is a commit operation, the configuration change data in the candidate configuration library is merged or switched to the running configuration library. The routing protocol stack is notified through an in-process interface, and the routing protocol stack reads the configuration change data from the running configuration library and applies it. When the operation type is a rollback operation, the configuration change data in the candidate configuration library is discarded, and the running configuration library remains unchanged.

[0045] As one possible implementation, a single-process embedded NETCONF configuration management system also includes: The configuration entry adaptation module sets up a configuration entry adaptation layer within the routing control plane management process. When a configuration request is received through a non-NETCONF configuration entry, the configuration entry adaptation layer parses the configuration request to obtain the configuration command and maps the configuration command to a standard editing operation on the data storage instance. The standard editing operation and the NETCONF configuration editing operation use the same data read / write rules and verification rules.

[0046] Thirdly, the present invention provides a terminal including a processor and a communication interface coupled to the processor, wherein the processor is used to run computer programs or instructions to implement the single-process embedded NETCONF configuration management method provided in the first aspect.

[0047] Although the invention has been described herein in conjunction with various embodiments, those skilled in the art will understand and implement other variations of the disclosed embodiments by reviewing the accompanying drawings, the disclosure, and the description of the drawings, in carrying out the claimed invention. In this specification, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple components. A single processor or other unit can implement several of the functions listed in the specification. While certain measures are described in different embodiments, this does not mean that these measures cannot be combined to produce good results.

[0048] Although the invention has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made therein without departing from the spirit and scope of the invention. Accordingly, this specification and drawings are merely illustrative of the invention and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of the invention. Clearly, those skilled in the art can make various alterations and modifications to the invention without departing from its spirit and scope. Thus, if such modifications and modifications fall within the scope of the invention and its equivalents, the invention is also intended to include such modifications and modifications.

Claims

1. A single-process embedded NETCONF configuration management method, characterized in that, Includes the following steps: S1. Start the routing control plane management process, load and parse the YANG model file, and build the YANG data tree; S2. Create a data storage instance within the routing control plane management process. The data storage instance includes at least a runtime configuration library and a candidate configuration library. Each data storage instance corresponds to an independent YANG data tree. Initialize the NETCONF server module and put it into listening state. S3. After establishing a session with the NETCONF client, the NETCONF server module receives RPC requests within the routing control plane management process, parses XML messages to extract the operation type, NETCONF configuration change data, and target path; The S4.NETCONF server module calls the data storage instance through the interface within the routing control plane management process to read and write configuration change data based on the operation type. S5. When the operation type is an edit configuration operation, write the configuration change data to the candidate configuration library; when the operation type is a submit operation, merge or switch the configuration change data in the candidate configuration library to the running configuration library, notify the routing protocol stack through the in-process interface, and the routing protocol stack reads the configuration change data from the running configuration library and applies it; when the operation type is a rollback operation, discard the configuration change data in the candidate configuration library and keep the running configuration library unchanged.

2. The single-process embedded NETCONF configuration management method according to claim 1, characterized in that, Before writing configuration change data into the candidate configuration library, the configuration change data is validated based on the YANG data tree corresponding to the candidate configuration library. The validation includes at least: syntax validation, constraint validation, and dependency validation.

3. The single-process embedded NETCONF configuration management method according to claim 2, characterized in that, The single-process embedded NETCONF configuration management method also includes: A configuration entry adaptation layer is set up within the routing control plane management process. When a configuration request is received through a non-NETCONF configuration entry, the configuration entry adaptation layer parses the configuration request to obtain the configuration command and maps the configuration command to a standard editing operation on the data storage instance. The standard editing operation uses the same data read / write rules and verification rules as the NETCONF configuration editing operation.

4. The single-process embedded NETCONF configuration management method according to claim 3, characterized in that, The non-NETCONF configuration entry point includes at least a command-line interface (CLI); the configuration entry point adaptation layer includes at least NETCONF configuration functions.

5. The single-process embedded NETCONF configuration management method according to claim 4, characterized in that, The NETCONF configuration functions can be obtained using the following method: The NETCONF-side processing flow and the command-line-side processing flow are modeled in a unified manner and abstracted into a common configuration processing link. Non-common processes caused only by differences in the entry protocol are semantically mapped at the configuration entry adaptation layer so that they can be incorporated into the common configuration processing link. The configuration interface functions in the common configuration processing link are extracted as NETCONF configuration functions.

6. The single-process embedded NETCONF configuration management method according to claim 3, characterized in that, The following method maps configuration commands to standard editing operations on data store instances: The NETCONF server module parses XML messages, extracts configuration change data and target paths, and generates NETCONF standard edit requests; the command-line interface (CLI) parses configuration commands, extracts command-line configuration change data and binds it to the target path, and generates CLI standard edit requests that are isomorphic to NETCONF; both NETCONF standard edit requests and CLI standard edit requests are applied to the data storage instance according to the corresponding target path.

7. The single-process embedded NETCONF configuration management method according to claim 1, characterized in that, Notifying the routing protocol stack via an in-process interface includes: invoking a pre-registered callback function by the data storage instance; and / or sending configuration change messages via inter-process event notification.

8. A single-process embedded NETCONF configuration management system, characterized in that, include: The YANG data tree construction module starts the routing control plane management process, loads and parses the YANG model file, and constructs the YANG data tree. The data storage module creates data storage instances within the routing control plane management process. Each data storage instance includes at least a runtime configuration library and a candidate configuration library, and each data storage instance corresponds to an independent YANG data tree. The NETCONF server module initializes and enters a listening state. After establishing a session with the NETCONF client, the NETCONF server module receives RPC requests within the routing control plane management process, parses XML messages to extract the operation type, NETCONF configuration change data, and target path. The NETCONF server module calls the data storage instance through the interface of the routing control plane management process, and reads and writes configuration change data based on the operation type. The transaction commit module, when the operation type is an edit configuration operation, writes the configuration change data into the candidate configuration library. Before writing the configuration change data into the candidate configuration library, it verifies the configuration change data based on the YANG data tree corresponding to the candidate configuration library. The verification includes at least: syntax verification, constraint verification and dependency verification. When the operation type is a commit operation, the configuration change data in the candidate configuration library is merged or switched to the running configuration library. The routing protocol stack is notified through the in-process interface, and the routing protocol stack reads the configuration change data from the running configuration library and applies it. When the operation type is a rollback operation, the configuration change data in the candidate configuration library is discarded, and the running configuration library remains unchanged.

9. The single-process embedded NETCONF configuration management system according to claim 8, characterized in that, The single-process embedded NETCONF configuration management system also includes: The configuration entry adaptation module sets up a configuration entry adaptation layer within the routing control plane management process. When a configuration request is received through a non-NETCONF configuration entry, the configuration entry adaptation layer parses the configuration request to obtain the configuration command and maps the configuration command to a standard editing operation on the data storage instance. The standard editing operation uses the same data read / write rules and verification rules as the NETCONF configuration editing operation.

10. A terminal, characterized in that, It includes a processor and a communication interface coupled to the processor, the processor being used to run computer programs or instructions to implement the single-process embedded NETCONF configuration management method as described in any one of claims 1 to 7.

Images