Patent Description:
This disclosure relates to computer networks and, more particularly, to techniques for configuring and managing network devices.

A computer network is a collection of interconnected computing devices that can exchange data and share resources. In a packet-based network, such as an Ethernet network, the computing devices communicate data by dividing the data into small blocks called packets, which are individually routed across the network from a source device to a destination device. A variety of intermediate devices operate to route the packets between the computing devices. For example, a computer network may include routers, switches, gateways, firewalls, and a variety of other devices to provide and facilitate network communication.

These network devices typically include mechanisms, such as management interfaces, for locally or remotely configuring the devices. By interacting with the management interface, various clients, such as human users, automated scripts or network management systems, can perform configuration tasks as well as collect and view operational data of the managed devices. For example, the clients may configure interface cards of the device, adjust parameters for supported network protocols, specify physical components within the device, modify routing information maintained by a router, access software modules and other resources residing on the device, and perform other configuration tasks.

The Network Configuration Protocol (NETCONF) is a standard defined by the Internet Engineering Task Force (IETF) that provides mechanisms to install, manipulate, and delete the configuration of network devices. By interacting with the management interface, clients can use NETCONF to apply configuration changes at network devices on a network. https://www. rfc-editor. org/rfc/pdfrfc/rfc3416. pdf(XP55821008) relates to Version <NUM> of the Protocol Operations for the Simple Network Management Protocol (SNMP).

In general, this disclosure describes techniques for concurrently updating a network device with multiple configuration transactions in a single configuration change request where each transaction can be separately committed to the database and rolled-back if needed. For example, techniques described herein may permit a network management system to generate and output a configuration change request that includes multiple sub-transactions, each sub-transaction specifying one or more configuration changes to be pushed to a network device. The network device may concurrently commit the configuration changes specified by the multiple sub-transactions and generate a single reply message, where the reply message includes a respective response element for each requested sub-transaction and which indicates whether the configuration change specified by each of the corresponding sub-transactions was successfully committed at the network device. In some examples, techniques for concurrently updating a network device may include dividing a batch of configuration change requests for network devices that do not support sub-transaction identifiers.

For example, this disclosure describes a new form of a Network Configuration Protocol (NETCONF) configuration transaction request that allows multiple sub-transactions of configuration changes to be specified in a single NETCONF message. Moreover, the disclosure describes a new form of a NETCONF configuration reply message by which the managed device is able to indicate whether each of the configuration sub-transactions was successfully committed to the managed device.

Further, the disclosure also describes extensions to a higher-level service model utilized by the network management system. As described, the extension allows the service model to control the use and format of a network configuration change request for specifying concurrent configuration sub-transactions when configuring a managed device, such as when configuring a network service on the managed device.

The techniques may provide certain technical advantages, such as potentially reducing an amount of network resources utilized and/or time required to configure network devices. As one example, the techniques may be particularly advantageous, for example, in network systems in which a hub-and-spoke virtual private network (VPN) is being provisioned, especially in a large network environment where multiple customer VPN sites are being provisioned. For example, the techniques may permit provisioning multiple customer sites on a hub router by issuing a single NETCONF configuration change message that includes multiple sub-transactions, each sub-transaction specifying configuration data to be provisioned on the hub router for a respective customer site being brought online. As described, the techniques allow the sub-transactions to be committed concurrently and for the managed network router to issue a single reply message the indicates which of the sub-transactions succeeded and which failed, if any.

This disclosure describes a method performed by a managed device of a network, the method comprising: receiving, by processing circuitry of the managed device, from a network management system, a single configuration change request representing a transaction having a plurality of sub-transactions, wherein each sub-transaction of the plurality of sub-transactions specifies one or more respective configuration changes for the managed device; selectively installing, by the processing circuitry, for each sub-transaction of the plurality of sub-transactions, the one or more respective configuration changes at the managed device; constructing, by the processing circuitry, a reply message based on the selectively installing, wherein the reply message comprises, for each sub-transaction of the plurality of sub-transactions, a respective response element indicating whether the managed device committed the one or more respective configuration changes in a running configuration for the managed device; and outputting, by the processing circuitry, to the network management system, the reply message.

In one example, this disclosure describes a computing device comprising means for performing the above-described methods.

In one example, this disclosure describes a computer-readable medium encoded with instructions for causing one or more programmable processors to perform the above-described methods.

The details of one or more examples of the techniques of this disclosure are set forth in the accompanying drawings and the description below.

<FIG> is a block diagram illustrating elements of an enterprise network <NUM> that are managed using a network management system <NUM>. Managed elements 5A-<NUM> (collectively, elements <NUM>) of enterprise network <NUM> are existing network devices interconnected via communication links to form a communication topology in order to exchange resources and information. Elements <NUM> may include, for example, routers, switches, gateways, bridges, hubs, servers, firewalls or other intrusion detection systems (IDS) or intrusion prevention systems (IDP), computing devices, computing terminals, printers, other network devices, or a combination of such devices. While described in this disclosure as transmitting, conveying, or otherwise supporting packets, enterprise network <NUM> may transmit data according to any other discrete data unit defined by any other protocol, such as a cell defined by the Asynchronous Transfer Mode (ATM) protocol, or a datagram defined by the User Datagram Protocol (UDP). Communication links interconnecting elements <NUM> may be physical links (e.g., optical, copper, and the like) or wireless.

Enterprise network <NUM> is shown coupled to public network <NUM> (e.g., the Internet) via communication link <NUM>. Public network <NUM> may include, for example, one or more client computing devices. Public network <NUM> may provide access to web servers, application servers, public databases, media servers, end-user devices, and other types of network resource devices and content. Network devices in public network <NUM> may present a number of security threats to enterprise network <NUM>. For example, devices in public network <NUM> may attempt to deliver worms, trojans, and/or viruses to one or more of elements <NUM>. As another example, a hacker using a device in public network <NUM> may attempt to infiltrate enterprise network <NUM> to snoop, corrupt, destroy, or steal information stored by one or more of elements <NUM>.

Network management system <NUM> is communicatively coupled to elements <NUM> via enterprise network <NUM>. Network management systems <NUM> may be coupled either directly or indirectly to the various elements <NUM>. Once elements <NUM> are deployed and activated, administrator <NUM> may use network management system <NUM> to manage elements <NUM> using a management protocol designed for management of configuration data within elements <NUM>, such as the Simple Network Management Protocol (SNMP), or the Network Configuration (NETCONF) protocol, or a derivative thereof, such as the Juniper Device Management Interface, to perform the configuration. Details of the NETCONF protocol may be found at<NPL>.

In common practice, network management system <NUM> and elements <NUM> managed by network management system <NUM> are centrally maintained by an IT group of the enterprise and are collectively referred to as an element management system (EMS) or a network management system (NMS). Administrator <NUM> interacts with network management system <NUM> to remotely monitor and configure elements <NUM>. For example, administrator <NUM> may receive alerts from network management system <NUM> regarding any of elements <NUM>, view configuration data of elements <NUM>, modify the configurations data of elements <NUM>, add new network devices to enterprise network <NUM>, remove existing network devices from enterprise network <NUM>, or otherwise manipulate the enterprise network <NUM> and network devices therein. Although described with respect to an enterprise network, the techniques of this disclosure are applicable to other network types, public and private, including LANs, VLANs, VPNs, and the like.

Administrator <NUM> uses network management system <NUM> to configure elements <NUM> to specify certain operational characteristics that further the objectives of administrator <NUM>. For example, administrator <NUM> may specify for an element <NUM> a particular operational policy regarding security, device accessibility, traffic engineering, quality of service (QoS), network address translation (NAT), packet filtering, packet forwarding, rate limiting, or other policies. Network management system <NUM> uses a network management protocol designed for management of configuration data within managed network elements <NUM>, such as the SNMP protocol or the NETCONF protocol or a derivative thereof, such as the Juniper Device Management Interface, to perform the configuration.

In general, NETCONF provides mechanisms for configuring network devices and uses an Extensible Markup Language (XML)-based data encoding for configuration data, which may include policy data. NETCONF is described in <NPL>. Network management system <NUM> may establish NETCONF sessions with one or more of elements <NUM>. In the example of <FIG>, network management system <NUM> participates in NETCONF sessions 9A-9C with elements 5A-5C, respectively.

Network management system <NUM> may "serially push" configuration changes to each one of elements <NUM>. For example, network management system <NUM> may send a first configuration change request for a first set of configuration changes and upon receiving a reply message indicating whether the first set of configuration changes are committed, send a second configuration change request for a second set of configuration changes. However, serially pushing configuration changes may slow down an activation of elements <NUM>, particularly in application where many elements <NUM> are activated concurrently (e.g., software-driven wide-area networks) such that a single element (e.g., hub device) has many sets of configuration changes to be applied.

In the example of <FIG>, network management system <NUM> extends NETCONF to "concurrently push" configurations changes of one or more of network elements <NUM> in accordance with various aspects of the techniques described in this disclosure. For example, network management system <NUM> uses the device management protocol (e.g., NETCONF) to remotely configure elements <NUM> and, as described herein, uses an extended device management protocol that enables network management system <NUM> to specify multiple sub-transactions in a single configuration change request, where each sub-transaction include one or more configuration changes to be separately committed on managed network element <NUM> receiving the request. For instance, network management system <NUM> may send, to element 5C, a single configuration change request that specifies both a first sub-transaction for a first set of configuration changes and a second sub-transaction for a second set of configuration changes. In this instance, upon or while installing the first set of configuration changes at element 5C, element 5C independently installs, without further interaction with network management system <NUM>, the second set of configuration changes. Moreover, element 5C may install each of the first set and second set of configuration changes as independent "commits" to the underlying configuration database such that each of the first and second configuration changes may be separately rolled-back, if needed. In accordance with the techniques described herein, element 5C generates a single reply message indicating whether the first set of configuration changes and the second set of configuration changes are committed.

In some examples, network management system <NUM> may operate in accordance with one or more high-level service models that provides a definition for a network service, such as a virtual private network to be deployed across managed elements <NUM> within network <NUM>. In addition, network management system <NUM> may operate according to one or more low-level device models that specify the mechanisms to be used to configure each of managed network elements <NUM>, which may constitute network devices of different types (e.g., firewalls, routers, switches, gateways, and the like) from different manufactures, thereby having different interface and configuration requirements. As described herein, in some examples, one or more of the high-level service models is extended, as described herein, to define an additional model object (e.g., a multiplexer object), that is used to control the properties and format of the extended configuration change request used by network management system <NUM>, as controlled by the low-level device model, when interacting with one or more managed elements <NUM> to install multiple sub-transactions in a single configuration change request. In this way, the techniques provide certain technical advantage in which support and use of the low-level extensions to the device management protocol, e.g., NETCONF, can be easily controlled by and enabled for high-level network services.

<FIG> is a block diagram illustrating one example use case for the techniques described herein. In particular, <FIG> illustrates an example of a hub-and-spoke virtual private network (VPN) configuration of network elements <NUM> (shown in this example as a hub router 5A and spoke routers 5B-5E servicing respective client sites 51B-<NUM>). In networks such as the example shown in <FIG>, network management system <NUM> provisions an end-to-end VPN network service across the network by installing respective configuration data within hub router 5A and spoke routers 5B-<NUM>. In general, network management system configures each of spoke routers 5B-<NUM> with respective configuration data necessary to operate as a spoke within the VPN service, and separately configures and validates configuration data for each client site <NUM> on hub router 5A. In other words, in generally, network management system <NUM> typically directs hub router 5A to install and validate distinct configuration data for each client site <NUM> as the client sites are brought online in the VPN service. Without the technical advantages of the techniques described herein, the configuration of hub router in this context can easily become a bottleneck, especially large scale service provider networks, when provisioning network services. As illustrated herein, the techniques enable network management system <NUM> to specify multiple sub-transactions 52B-<NUM> in a single configuration change request 50A, where each sub-transaction include one or more configuration changes to be separately committed on hub router 5A. Hub router 5A installs, without further interaction with network management system <NUM>, the configuration changes for each sub-transaction as independent "commits" to the underlying configuration database such that the configuration changes for any sub-transaction may be separately validated and rolled-back, if needed. In accordance with the techniques described herein, hub router 5A generates a single reply message <NUM> indicating whether the configuration changes for each of the sub-transactions 52B-<NUM> have been successfully committed and validated. In this example, network management system <NUM> may send also configuration change requests 50B-<NUM> to a respective spoke router 5B-<NUM> that form spokes of the example hub and spoke configuration. Each of spoke routers 5B-<NUM> operates to commit the configuration data specified in change requests 50B-<NUM> and outputs replies (not shown) indicating whether the configuration data has been successfully committed. In this case, the configuration change requests 50B-<NUM> issued by network management system <NUM> to spoke routers 5B-<NUM> may be conventional change requests or may be extended change requests as described herein that specify multiple concurrent sub-transactions.

As described herein, network management system <NUM> may operate in accordance with one or more high-level service models <NUM> that each provides a definition for a network service, such as the hub-and-spoke virtual private network to be deployed across routers <NUM>. In addition, network management system <NUM> may operate according to one or more low-level device models <NUM> that specify the mechanisms to be used to configure each of routers <NUM>. As one example, network management system <NUM> may be configured to operate in accordance with service models <NUM> that conform to a YANG model, which is described in <NPL>). In the hub and spoke example of <FIG>, service models <NUM> may, for example, conform to the YANG data modeling language and provide the high-level definition of the network services to be deployed, including the VPN service. In response to input from administrator <NUM>, network management system operates in accordance with service models <NUM> and device models <NUM> to install the necessary configuration data at hub router 5A and spoke routers 5B-<NUM> to provision the network service and bring online the VPN service for each of the client sites <NUM>. Said differently, for example, spoke routers 5B-<NUM> that would be joining the VPN service are configurated with corresponding configuration data so as to communicate through hub router 5A, and hub router 5A is configured to support each of client sites <NUM>, thereby forming the hub-and-spoke VPN service. Though all these configuration changes may each have a respective requirements at the application level (e.g., YANG model), in some systems, the application-level requirements are translated into a respective transaction of configuration changes at the hub (e.g., element 5A) in accordance with device models <NUM>. As such, to accommodate the hub and spoke configuration, network management system <NUM> may push separate configuration change requests to accommodate configuration changes at elements 5B-<NUM>, which form spokes of the example hub and spoke configuration. For example, network management system <NUM> may send a first configuration change request to accommodate configuration changes at element 5B, output a second configuration change request to element SAto accommodate configuration changes at 5C, and so forth. Moreover, each of spoke routers 5B and corresponding client sites 51B-<NUM> often requires separate provisioning and validation of configuration data on hub router 5A as the client sites are brought online. As described above, serially pushing configuration changes, as may be required with conventional protocols and techniques, to hub router 5A for separate commit and validation may slow down activation of spoke routers 5B-<NUM> and deployment of the overall network service.

In the example of <FIG>, network management system <NUM> extends one or more of service models <NUM> to translate application level service requirements into a respective sub-transaction of configuration changes at the hub router 5A in accordance with various aspects of the techniques described in this disclosure. In this way, the techniques provide certain technical advantage in which support and use of the low-level extensions to the device management protocol, e.g., NETCONF, can be easily controlled by and enabled for high-level network services. As one example, the YANG model may include an extension defining a multiplexer "ext: multiplexer", an example of which follows.

In some examples, network management system <NUM> may set the multiplexer identifier ("id") to include a hub name and identifier value. For example, network management system <NUM> may set the multiplexer identifier ("id") to include a hub name for hub router 5A when spoke routers 5B-<NUM> are solely for a common tenant. In examples, where hub router 5A and spoke routers 5B-<NUM> is configured for a multi-tenant configuration (e.g., Multi-Tenant SD-WAN) so as to service multiple, different VPNs for different customers, element 5A may set the multiplexer identifier ("id") to include a hub name, a tenant identifier ("Tenant-id"), and identifier value, an example of which follows. extmultiplexer {
ext:id {
extpath: ["/sdwan/tenant-id","/sdwan/hub"].

In the example of <FIG>, network management system <NUM> extends NETCONF, as one example, to "concurrently push" configurations changes to hub router 5A in accordance with various aspects of the techniques described in this disclosure. For example, network management system <NUM> may send, to hub router 5A, a single configuration change request 50A that specifies sub-transaction 52B for configuration changes required to support spoke router 5B, sub-transaction 52C for configuration changes required to support spoke router 5C, sub-transaction 52D for configuration changes required to support spoke router 5D, sub-transaction 52E for configuration changes required to support spoke router 5E, and so forth. In this instance, upon installing configuration changes of sub-transaction 5B at hub router 5A, hub router 5A installs, without further interaction with network management system <NUM>, configuration changes of sub-transaction 5C, and so forth until configuration changes of sub-transactions 5B-<NUM> are installed (committed and validated) at element 5A and generates a single reply message indicating which of the sub-transactions of sub-transactions 52B-<NUM> were successfully committed and which, if any, failed and should be rolled back.

<FIG> is a block diagram illustrating more generally an example network management system <NUM> and an example managed device <NUM> that concurrently commits multiple sub-transactions in accordance with one or more aspects of this disclosure. Network management system <NUM> manages managed device <NUM> using a management protocol, such as NETCONF, for exchanging management protocol messages over a communication link. Network management system <NUM> may also be referred to as network management devices in this disclosure. While described with respect to one particular protocol for managing network devices, e.g., NETCONF, techniques of this disclosure may apply to any network management protocol that provides mechanisms to install, manipulate, and delete the configuration of network devices.

Network management system <NUM> may be an example of a network management system <NUM> of <FIG> and managed device <NUM> may be an example of element 5A of <FIG>. In the example illustrated in <FIG>, network management system <NUM> includes control unit <NUM> and managed device <NUM> includes network interface <NUM> and control unit <NUM>.

Each of control unit <NUM> and control unit <NUM> may include one or more processors that execute software instructions, such as those used to define a software or computer program, stored to a computer-readable storage medium, such as a storage device (e.g., a disk drive, or an optical drive), or memory (such as Flash memory, random access memory or RAM) or any other type of volatile or non-volatile memory, that stores instructions to cause a programmable processor to perform the techniques described herein. Alternatively, control unit <NUM> may comprise dedicated hardware, such as one or more integrated circuits, one or more Application Specific Integrated Circuits (ASICs), one or more Application Specific Special Processors (ASSPs), one or more Field Programmable Gate Arrays (FPGAs), or any combination of one or more of the foregoing examples of dedicated hardware, for performing the techniques described herein.

Control unit <NUM> provides an operating environment for administrative interface (ADMIN INTERFACE) <NUM>, service layer <NUM>, and device management layer <NUM>. Generally, service layer <NUM> may be responsible for generating the request in accordance with service models <NUM> and passing the request to management module <NUM> within device management layer <NUM>. Further, device management layer <NUM> may be responsible for constructing a configuration change request in accordance with device models <NUM>. As shown, service layer <NUM> includes service models <NUM>. Device management layer <NUM> includes management module <NUM> and configuration data (CONFIG DATA) <NUM>.

Service models <NUM> may include an application level model (e.g., Yet Another Next Generation model or simply "YANG model") that may be used to model configuration and state data manipulated by the NETCONF, NETCONF remote procedure calls, and NETCONF notifications. YANG is described in <NPL>. For example, service models <NUM> may receive, via administrator interface <NUM>, an application level configuration for managed device <NUM>. In this example, the application level configuration may be in accordance with the YANG model. Service models <NUM> may translate the application level configuration from the YANG model into configuration changes for device models <NUM>.

Management module <NUM> represents an example instance of a management application (e.g., NETCONF) or, more generally, a network management application. Management module <NUM> is one example of a network management module. In one example, management module <NUM> provides mechanisms to install, manipulate, and delete the configuration of network devices of elements <NUM> of <FIG> and/or managed device <NUM>. Device models <NUM> may include a low level or device level model (e.g., NETCONF") that may be used to model configuration change requests. Concurrent configuration module (CONCURRENT CONFIG ENGINE) <NUM> may be configured to implement one or more techniques described herein for concurrently committing multiple sub-transactions.

Managed device <NUM> may be any device having one or more processors and a memory, and that is capable of executing one or more software processes, including concurrent configuration engine <NUM>, that operates in accordance with a network management protocol, such as NETCONF. Managed device <NUM> stores a running configuration for forwarding network packets in configuration data (CONFIG DATA) <NUM>. Control unit <NUM> of device <NUM> provides an operating environment for concurrent configuration engine <NUM> and configuration data <NUM>. Configuration data <NUM> may be stored in a data repository and may each store data in the form of one or more tables, databases, linked lists, radix trees, or other suitable data structure.

A network operator or other administrator interacts with administrative interface <NUM> to direct management module <NUM> to manage device <NUM> in a specified manner, e.g., to modify the configuration of device <NUM>. For example, the administrate may enter commands to modify configuration data <NUM> and ultimately to deploy the configuration data to configuration data <NUM> as a running configuration of managed device <NUM>.

In accordance with one or more techniques described herein, network management system <NUM> extends one or more of service models <NUM> to translate application level service requirements into a respective sub-transaction of configuration changes at managed device <NUM> in accordance with various aspects of the techniques described in this disclosure. In this way, the techniques provide certain technical advantage in which support and use of the low-level extensions to the device management protocol, e.g., NETCONF, can be easily controlled by and enabled for high-level network services.

Further, in accordance with one or more techniques described herein, concurrent configuration module <NUM> may generate a configuration change request in the form of a single message representative of an overall transaction <NUM> that includes sub-transactions 52A-52N (collectively, sub-transactions <NUM>), where each sub-transaction specifies a corresponding set of configuration change(s), e.g., insertions, deletions and/or modifications, and where each set of configuration changes can be separately committed and validated by managed device <NUM> to the underlying configuration data <NUM> of the device even though contained in the same request. In some examples, concurrent configuration module <NUM> generates transaction <NUM> in accordance with device models <NUM> (e.g., NETCONF). In this example, each sub-transaction of sub-transactions <NUM> specifies multiple respective configuration changes for managed device <NUM>, while in some examples, one or more sub-transactions of sub-transactions <NUM> may specify a single respective configuration change for managed device <NUM>. As shown, concurrent configuration module <NUM> outputs the request to managed device <NUM>.

Network interface <NUM> receives the request indicating transaction <NUM> including sub-transactions <NUM>. Concurrent configuration engine <NUM> selectively installs, for each sub-transaction of sub-transactions <NUM>, respective configuration changes at configuration data <NUM> of managed device <NUM>. For example, concurrent configuration engine <NUM> applies configuration changes for sub-transactions 52A and determines whether the configuration changes for sub-transactions 52A are committed in a running configuration stored at configuration data <NUM>. In this example, concurrent configuration engine <NUM> may "roll-back" configuration changes when the configuration changes are not each committed in the running configuration (e.g., a particular configuration change is not supported by managed device <NUM>). In this way, concurrent configuration engine <NUM> may help to ensure that either each configuration change of a sub-transaction is committed at the running configuration or that none of the configuration changes of a sub-transaction are committed at the running configuration.

Concurrent configuration engine <NUM> constructs reply message <NUM> based on the selectively installing. In this example, reply message <NUM> includes, for each sub-transaction of sub-transactions <NUM>, a corresponding response element of response elements 56A-56N (collectively, response elements <NUM>) indicating whether managed device <NUM> committed the respective configuration changes in a running configuration for managed device <NUM>. For example, concurrent configuration engine <NUM> generates response element 56A as a negative response in response to determining managed device <NUM> does not commit configuration changes for sub-transaction 52A. In some examples, concurrent configuration engine <NUM> generates response element 56N as a positive response in response to determining managed device <NUM> commits configuration changes for sub-transaction 52N. As shown, network interface <NUM> outputs the reply to network management system <NUM>.

Concurrent configuration module <NUM> updates configuration data <NUM> based on reply message <NUM>. For example, in response to receiving reply message <NUM> including response element 56A specifying configuration changes for sub-transaction 52A are not successfully committed at managed device <NUM>, concurrent configuration module <NUM> refrains from updating configuration data <NUM> to include the configuration changes for sub-transaction 52A. In response to receiving reply message <NUM> including response element 56N specifying configuration changes for sub-transaction 52N are successfully committed at managed device <NUM>, concurrent configuration module <NUM> updates configuration data <NUM> to include the configuration changes for sub-transaction 52N.

<FIG> is a flowchart illustrating an example operation of a network management system that splits sub-transactions of a configuration change request in accordance with the techniques of the disclosure. <FIG> is described with respect to network management system <NUM> of <FIG> for example purposes only. In the example of <FIG>, a network management system divides a batch of configuration change requests when a network device does not support sub-transaction identifiers.

Initially, administrator interface <NUM> receives application level configuration changes and one or more multiplexer identifiers (<NUM>). For example, administrator interface <NUM> receives the application level configuration changes and multiplexer identifiers from administrator <NUM>. Service layer <NUM> translates the application level configuration changes into low level configuration changes (<NUM>). For example, service layer <NUM> translates, using the YANG model of service models <NUM>, an application level configuration change of the application level configuration corresponding to a multiplexer identifier (e.g., hub name, hub name and tenant identifier, etc.) into a configuration change of a low level configuration of device models <NUM> (e.g., NETCONF). However, in the example of <FIG>, the network device does not support sub-transaction identifiers. As such, the configuration change of a low level configuration of device models <NUM> in the example of <FIG> does not include a sub-transaction identifier.

Device management layer <NUM> receives a commit request from service layer <NUM>, where service layer <NUM> has generated the commit request according to service models <NUM> (e.g., according to the multiplexer extension of the YANG model) and has pushed the commit request down to device management layer <NUM> (commit request) (<NUM>). Concurrent configuration module <NUM> internally batches the configuration changes from the service layer (<NUM>).

Concurrent configuration module <NUM> may be configured to generate device level configuration change requests in accordance with device models <NUM> (e.g., NETCONF). For example, concurrent configuration module <NUM> may concurrently send "multiple sub-transactions" as part of a transaction (e.g., edit-config) without using a sub-transaction identifier. Concurrent configuration module <NUM> populates configuration change requests with config-path tokens (<NUM>). For example, in one example, concurrent configuration module <NUM> include <NUM> tokens in the config paths that are part of configuration. Concurrent configuration module <NUM> generates a configuration change request (edit-config and commit config) (<NUM>). For example, concurrent configuration module <NUM> generates, in accordance with a device management protocol (e.g., NETCONF), a configuration change request representing a transaction specifying a batch of configuration changes for a network device. In this example, concurrent configuration module <NUM> may output the configuration change request and receive a reply message.

Concurrent configuration module <NUM> determines whether the commit is successful (<NUM>). If all response elements of a reply message are positive ("Yes" of <NUM>), concurrent configuration module <NUM> prepares and returns a response (<NUM>). For example, concurrent configuration module <NUM> outputs a return success to a caller (e.g., administrator <NUM>).

Again, in some examples, all network devices may not support sub-transaction identifiers. In those cases, a "device management" layer in network management system <NUM> may handle concurrent transactions. For example, concurrent configuration module <NUM> may batch configuration changes and commit the batched configuration changes all together. Accordingly, in response to receiving a negative response element ("No" of <NUM>), concurrent configuration module <NUM> may split the batch of sub-transactions based on an error message (<NUM>) and go to step <NUM>. For example, in response to receiving a reply message specifying the batch of configuration change are not successfully committed at the network device, concurrent configuration module <NUM> may divide the batch of configuration changes into a first sub-set of one or more configuration changes and a second sub-set of one or more configuration changes based on an error message indicated in the reply message.

While dividing the batch, concurrent configuration module <NUM> may use the "config-path token" present in commit-request. "Config-path token" may be the first <NUM> tokens in the configuration paths that are part of a configuration. Concurrent configuration module <NUM> may check the "error path config" and use the config-path token while splitting commit-requests. All the configurations whose configuration token matches the error response path may be part of a first group and all other configurations would be part of one or more other groups (e.g., a second group). While grouping the configs, concurrent configuration module <NUM> may also consider leaf-referred attributes (also referred to simply as "leafrefs").

Example pseudocode showing an example algorithm for implementing the above-described functionality is as follows:
<IMG>.

<FIG> is a flowchart illustrating an example operation of a network management system in accordance with the techniques of the disclosure. <FIG> is described with respect to network management system <NUM> of <FIG> for example purposes only. In the example of <FIG>, a network device supports sub-transaction identifiers.

Initially, administrator interface <NUM> receives application level configuration changes and one or more multiplexer identifiers (<NUM>). For example, administrator interface <NUM> receives the application level configuration changes and multiplexer identifiers from administrator <NUM>.

Service layer <NUM> translates the application level configuration changes into low level configuration changes (<NUM>). For example, service layer <NUM> translates, using the YANG model of service models <NUM>, a first application level configuration change of the application level configuration corresponding to a first multiplexer identifier (e.g., hub name, hub name and tenant identifier, etc.) into a first configuration change of a low level configuration of device models <NUM> (e.g., NETCONF) corresponding to a first sub-transaction identifier. In this example, service layer <NUM> may translate, using the YANG model of service models <NUM>, a second application level configuration change of the application level configuration corresponding to a second multiplexer identifier (e.g., hub name, hub name and tenant identifier, etc.) into the second configuration change of the low level configuration of device models <NUM> (e.g., NETCONF) corresponding to a second sub-transaction identifier.

Concurrent configuration module <NUM> generates a configuration change request representing a transaction having sub-transactions for configuration changes (<NUM>). For example, concurrent configuration module <NUM> generates the configuration change request representing transaction <NUM> having a first sub-transaction 52A that indicates a first sub-transaction identifier and a second sub-transaction 52B that indicates a second sub-transaction identifier.

In some examples, a network device may (as part of discovery) publish (e.g., to concurrent configuration module <NUM>) support for a transaction including multiple sub-transactions by the following string
urn:ietf:params:NETCONF:capability: concurrent-transactions: <NUM>. In this example, concurrent configuration module <NUM> may generate, for the network device, the configuration change request representing transaction <NUM> having a first sub-transaction 52A that indicates a first sub-transaction identifier and a second sub-transaction 52B that indicates a second sub-transaction identifier in response to receiving the string urn:ietf:params:NETCONF:capability: concurrent-transactions: <NUM> from the network device.

In some examples, the concurrent-transactions capability modifies <edit-config> operation to accept the sub-transaction identifier in a configuration node that defines the transaction scope of the change. In some examples, there can be <NUM> or more configuration nodes that define hierarchy of the configuration as defined by the device data model.

An example configuration change request is as follows. <IMG>
<IMG>.

Concurrent configuration module <NUM> outputs the configuration change request to a network device (<NUM>). For example, concurrent configuration module <NUM> outputs the configuration change request representing transaction <NUM> to managed device <NUM>.

Concurrent configuration module <NUM> receives a reply message from the network device including one or more response elements specifying whether a configuration change specified in a corresponding sub-transaction is successfully committed (<NUM>). For example, concurrent configuration module <NUM> receives reply message <NUM> from managed device <NUM> including response elements <NUM>. For example, concurrent configuration module <NUM> receives a reply message including a respective positive response element that an contains an <ok> element along with a respective sub-transactionid when a network device is able to satisfy the configuration changes of the respective sub-transaction. Similarly, concurrent configuration module <NUM> receives a reply message including a respective negative response element that an contains an <ipc-error> element along with a respective sub-transactionid when a network device is not able to satisfy the configuration changes of the respective sub-transaction. An example reply message is as follows. <rpc-reply message-id=" <NUM>"
xmlns="urn:ietf:params:xml:ns:NETCONF:base:<NUM>">
<ok sub-transactionid="a1234"/>
<ok sub-transactionid="a1235"/>
<ok sub-transactionid="a1236"/>
<rpc-error sub-transactionid="a1237">
<error-type>sub-transaction failed </error-type>
<error-tag>vlan-id is undefined </error-tag>
<error-severity>error</error-severity>
<error-message>
vlan-id is undefined
</error-message>
</rpc-error>
</rpc-reply>.

Concurrent configuration module <NUM> updates configuration data and devices the configuration changes (<NUM>). For example, concurrent configuration module <NUM> may update configuration data <NUM> to include the one or more configuration changes corresponding to one or more positive response elements of the reply message. Concurrent configuration module <NUM> prepares and returns a response (<NUM>). For example, concurrent configuration module <NUM> outputs a return success to a caller (e.g., administrator <NUM>).

<FIG> is a flowchart illustrating an example operation of a network management system that divides sub-transactions of a configuration change request in accordance with the techniques of the disclosure. <FIG> is described with respect to network management system <NUM> of <FIG> for example purposes only. In the example of <FIG>, a network management system divides a batch of configuration change requests when a network device does not support sub-transaction identifiers.

Initially, concurrent configuration module <NUM> may receive a reply message including a response element specifying configuration changes are not successfully committed at a network device (<NUM>). Concurrent configuration module <NUM> divides the configuration changes into a first sub-set of configuration changes that correspond to an error response path and a second sub-set of configuration changes that do not correspond to the error response path (<NUM>).

In response to determining that the first sub-set includes only a single configuration change ("YES" of <NUM>), concurrent configuration module <NUM> generates a configuration change request including a sub-transaction specifying the second sub-set of configuration changes (<NUM>). Concurrent configuration module <NUM> receives a reply message from a network device including a response element specifying whether the second sub-set of configuration changes is successfully committed (<NUM>).

In response, however, to determining that the first sub-set does not include only <NUM> configuration change ("NO" of <NUM>), concurrent configuration module <NUM> generates a configuration change request including a first sub-transaction specifying the first sub-set of configuration changes and a second sub-transaction specifying the second sub-set of configuration changes (<NUM>). Concurrent configuration module <NUM> receives a reply message from a network device including a first response element specifying whether the first sub-set of configuration changes is successfully committed and a second response element specifying whether the second sub-set of configuration changes is successfully committed (<NUM>).

<FIG> is a flowchart illustrating an example operation of a managed network device in accordance with the techniques of the disclosure. <FIG> is described with respect to managed device <NUM> of <FIG> for example purposes only. Initially, concurrent configuration engine <NUM> receives a configuration change request representing a transaction having a plurality of sub-transactions that each specify one or more configuration changes (<NUM>).

Concurrent configuration engine <NUM> selectively installs, for each sub-transaction of the plurality of sub-transactions, a corresponding set of one or more configuration changes based on the one or more respective configuration changes (<NUM>). For example, concurrent configuration engine <NUM> attempts to commit, for each sub-transaction of the plurality of sub-transactions, a corresponding set of one or more configuration changes to the running configuration stored at configuration data <NUM>.

Concurrent configuration engine <NUM> constructs a reply message based on the selective installing (<NUM>). For example, concurrent configuration engine <NUM> generates the reply message to include a negative response element for each sub-transaction having at least one configuration change that is not successfully committed and to include a positive response element for each sub-transaction having no configuration changes that are not successfully committed. In some examples, concurrent configuration engine <NUM> generates the reply message to include a negative response element and a respective sub-transaction identifier for each sub-transaction having at least one configuration change that is not successfully committed and to include a positive response element and a respective sub-transaction identifier for each sub-transaction having no configuration changes that are not successfully committed.

Concurrent configuration engine <NUM> outputs a reply message indicating the response elements (<NUM>). For example, concurrent configuration engine <NUM> outputs the reply message indicating the response elements to network management system <NUM>. Concurrent configuration engine <NUM> forwards network packets according to the running configuration (<NUM>). For example, concurrent configuration engine <NUM> forwards network packets according to the running configuration stored at configuration data <NUM>.

<FIG> is a flowchart illustrating an example operation of a managed network device that selectively installs sub-transactions in accordance with the techniques of the disclosure. <FIG> is described with respect to managed device <NUM> of <FIG> for example purposes only. Initially, concurrent configuration engine <NUM> stores, for each sub-transaction of a plurality of sub-transactions included in a configuration change request, a running configuration as a roll-back configuration (<NUM>). For example, concurrent configuration engine <NUM> stores "snapshot" of a running configuration stored at configuration data <NUM>.

Concurrent configuration engine <NUM> applies, for each sub-transaction of the plurality of sub-transactions, one or more configuration changes to a running configuration (<NUM>). For example, concurrent configuration engine <NUM> applies, for each sub-transaction of the plurality of sub-transactions, one or more configuration changes to a running configuration at configuration data <NUM>. Concurrent configuration engine <NUM> determines whether each sub-transaction has been committed (<NUM>). For example, concurrent configuration engine <NUM> validates whether a group of configuration changes for a sub-transaction are successfully committed at configuration data <NUM>.

In response to determining that the one or more configuration changes are not committed ("NO" of step <NUM>), concurrent configuration engine <NUM> sets the roll-back configuration to the running configuration as (<NUM>). For example, concurrent configuration engine <NUM> sets the roll-back configuration stored at configuration data <NUM> to the running configuration and generates a negative response element (<NUM>). In response, however, to determining that the one or more configuration changes are committed ("YES" of step <NUM>), concurrent configuration engine <NUM> generates a positive response element (<NUM>).

If implemented in hardware, this disclosure may be directed to an apparatus such as a processor or an integrated circuit device, such as an integrated circuit chip or chipset. Alternatively or additionally, if implemented in software or firmware, the techniques may be realized at least in part by a computer-readable data storage medium comprising instructions that, when executed, cause a processor to perform one or more of the methods described above. For example, the computer-readable data storage medium may store such instructions for execution by a processor.

A computer-readable medium may form part of a computer program product, which may include packaging materials. A computer-readable medium may comprise a computer data storage medium such as random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), Flash memory, magnetic or optical data storage media, and the like. In some examples, an article of manufacture may comprise one or more computer-readable storage media.

In some examples, the computer-readable storage media may comprise non-transitory media. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in RAM or cache). Additionally or alternatively, a computer-readable medium may include transient media such as carrier waves, propagated signals or transmission media.

Claim 1:
A method performed by a managed device of a network, the method comprising:
receiving (<NUM>), by processing circuitry of the managed device, from a network management system, a single configuration change request representing a transaction having a plurality of sub-transactions, wherein each sub-transaction of the plurality of sub-transactions specifies one or more respective configuration changes for the managed device;
selectively installing (<NUM>), by the processing circuitry, for each sub-transaction of the plurality of sub-transactions, the one or more respective configuration changes at the managed device;
constructing (<NUM>), by the processing circuitry, a reply message based on the selectively installing, wherein the reply message comprises, for each sub-transaction of the plurality of sub-transactions, a respective response element indicating whether the managed device committed the one or more respective configuration changes in a running configuration for the managed device; and
outputting (<NUM>), by the processing circuitry, to the network management system, the reply message.