Method, controller device, and medium for network management

Abstract

A topology compiler for a network management system. An example controller device that manages multiple network devices includes one or more processing units that are implemented in circuits and configured to receive an indication of an intent via an application programming interface (API) framework. The intent includes data indicating an update to a data structure that includes multiple nodes representing multiple network devices and multiple edges connecting the multiple nodes. The one or more processing units are also configured to process the intent to select a topology compiler from multiple topology compilers, and to call the selected topology compiler via the API framework using the roles of the network devices in the multiple network devices and the indication of the network devices as input to generate abstract configuration information. The one or more processing units are also configured to configure the network devices based on the abstract configuration information.

Description

[0001] This application claims the benefit of U.S. patent application No. 17 / 305,118, filed June 30, 2021, the entire contents of which are incorporated herein by reference. Technical Field

[0002] The present disclosure relates to computer networks, and more particularly, to management of network devices. Background Art

[0003] A computer network is a collection of interconnected computing devices capable of exchanging data and sharing resources. Various devices operate to facilitate communication between computing devices. For example, a computer network may include routers, switches, gateways, firewalls, and various other devices to provide and facilitate network communications.

[0004] These network devices typically include mechanisms for local or remote configuration of the device, such as a management interface. By interacting with the management interface, the client can perform configuration tasks and execute operational commands to collect and view operational data for the managed device. For example, the client can configure the device's interface card, 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 resident on the device, and perform other configuration tasks. In addition, the client can allow the user to view current operating parameters, system logs, information related to network connectivity, network activity, or other status information from the device, as well as view and react to event information received from the device.

[0005] Network configuration services can be performed by a variety of different devices, such as routers with service cards and / or dedicated service devices. These services include connectivity services such as Layer 3 virtual private networks (L3VPNs), virtual private local area network services (VPLS), and peer-to-peer (P2P) services. Other services include network configuration services such as Dot1q VLAN services. Network management systems (NMSs), also known as controllers or controller devices, and NMS devices can support these services, allowing administrators to easily create and manage these high-level network configuration services.

[0006] Specifically, user configurations of devices can be referred to as "intents." Intent-based networking systems allow administrators to describe intended network / compute / storage states. User intents can be categorized as business policies and stateless intents. Business policies or stateful intents can be parsed based on the current state of the network. Stateless intents can be a fully declarative way to describe intended network / compute / storage states, regardless of the current network state.

[0007] Intents can be represented as an intent data model, which can be modeled using a unified graph. The intent data model can be represented as a connected graph so that business policies can be implemented across the intent data model. For example, the data model can be represented using a connected graph with vertices connected using has-edges and reference (ref) edges. The controller device can model the intent data model as a unified graph so that the graph model can be represented as connected. In this way, business policies can be implemented across the intent data model. When intents are modeled using a unified graph model, extending support for new intents requires extending the graph model and compilation logic.

[0008] To configure a device to execute an intent, a user (such as an administrator) can write a translation program that translates high-level configuration instructions (e.g., instructions according to an intent data model, which can be represented as a unified graph model) into low-level configuration instructions (e.g., instructions according to a device configuration model). As part of the configuration service support, the user / administrator can provide an intent data model and a mapping between the intent data model and the device configuration model.

[0009] In order to simplify the definition of mappings for users, the controller device can be designed to provide the ability to define mappings in a simple way. For example, some controller devices provide the use of velocity templates and / or extensible stylesheet language transformations (XSLT). Such a translator contains the translation or mapping logic from the intent data model to the low-level device configuration model. Typically, a relatively small number of changes in the intent data model will affect a relatively large number of properties configured across devices. Different translators can be used when creating, updating, and deleting services from the intent data model. Summary of the Invention

[0010] In general, the present disclosure describes a technology for managing network devices. A network management system (NMS) device, also referred to herein as a controller or controller device, can be configured to translate a high-level configuration (an intention for multiple managed network devices received from an administrator) into a low-level configuration (the network device itself to be applied to the management). In some cases, the controller device can receive an indication of the topology and role of a resource device and generate device-level configuration information for the resource device. For example, an administrator (e.g., a person) can select a topology (e.g., spine or leaf, 3-level Clos or 5-level Clos) and a role for a resource device and provide an intention. In some examples, the controller device can generate a device-level configuration for a resource device based on the role, topology, and intention of the resource device. In some cases, the intention provided to the controller device by the administrator can be associated with multiple (e.g., more than 10, more than 20, etc.) roles. As the number of roles increases, the complexity of operating the controller device increases, which may cause the administrator to assign incorrect roles or topologies to the resource device, so that the controller device cannot correctly implement the intention.

[0011] According to the technology of this disclosure, a controller device can support multiple topology compilers, where each topology compiler is associated with a corresponding topology. For example, the first topology compiler can be associated with a 3-level Clos network, and the second topology compiler can be associated with a 5-level Clos network. The topology compiler can be configured to assign rules to each resource device, rather than relying on an administrator to assign roles to each resource device. In this way, setting up a structure using topologies can be achieved with less interaction from the administrator, which can improve the reliability of the structure.

[0012] In addition, each resource device that supports a topology can call a corresponding topology compiler assigned to that topology, rather than relying on an instruction set for all topologies. For example, a first resource device can call a level 3 Clos network topology compiler along with an indication of the role of the first resource device, and the level 3 Clos network topology compiler can generate an abstract configuration for the first resource device. In this example, the first resource device can generate device-level configuration information to configure the first resource device to implement the intent provided by the administrator. In this way, the resource controller for the resource device can automatically generate the necessary configuration information based on the selected topology, which can reduce the time used to configure the resource device to implement the intent.

[0013] Furthermore, the controller device can implement an "extensible framework" that allows one or more additional topology compilers to be added while maintaining a common framework. In this way, the controller device can be configured to support new topologies while operating on existing topologies at runtime without modifying the framework for the existing topologies.

[0014] In one example, a method includes receiving, by a controller device managing multiple network devices, an indication of an intent via an application programming interface (API) framework. The intent includes data indicating an update to a data structure, the data structure including multiple nodes representing the multiple network devices and multiple edges connecting the multiple nodes. The method also includes processing the intent by the controller device to select a topology compiler from multiple topology compilers, and calling the selected topology compiler by the controller device via the API framework using the role of the network device in the multiple network devices and the indication of the network device as input to generate abstract configuration information. The method also includes configuring the network device based on the abstract configuration information by the controller device.

[0015] In another example, a controller device that manages multiple network devices includes one or more processing units, which are implemented in a circuit and configured to receive an indication of an intent via an application programming interface (API) framework. The intent includes data indicating an update to a data structure, which includes multiple nodes representing multiple network devices and multiple edges connecting the multiple nodes. The one or more processing units are also configured to process the intent to select a topology compiler from multiple topology compilers, and to call the selected topology compiler via the API framework using the role of the network device in the multiple network devices and the indication of the network device as input to generate abstract configuration information. The one or more processing units are also configured to configure the network device based on the abstract configuration information.

[0016] In one example, a computer-readable storage medium having instructions stored thereon, the instructions, when executed, causing a processor of a controller device that manages multiple network devices to receive an indication of an intent via an application programming interface (API) framework. The intent includes data indicating an update to a data structure, the data structure including multiple nodes representing the multiple network devices and multiple edges connecting the multiple nodes. The instructions also cause the processor to process the intent to select a topology compiler from multiple topology compilers, and to call the selected topology compiler via the API framework using the roles of the network devices in the multiple network devices and the indication of the network devices as input to generate abstract configuration information. The instructions also cause the processor to configure the network device based on the abstract configuration information.

[0017] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 is a block diagram illustrating an example of elements including an enterprise network managed using a management device.

[0019] Figure 2 It is shown for Figure 1 A block diagram of an example component set of a management device.

[0020] Figure 3 is a conceptual diagram illustrating an example of assigning roles to elements according to the technology of this disclosure.

[0021] Figure 4 is a conceptual diagram illustrating an example of generating an abstract device configuration for a resource device according to the technology of this disclosure.

[0022] Figure 5 is a conceptual diagram illustrating an example of generating an abstract device configuration for a service device according to the technology of this disclosure.

[0023] Figure 6 is a conceptual diagram illustrating an example of generating a device-level configuration according to the technology of the present disclosure.

[0024] Figure 7 is a block diagram illustrating an example Clos network.

[0025] Figure 8 is a flow chart illustrating an example process for determining roles for network devices using a topology compiler, according to the techniques of this disclosure.

[0026] Figure 9 is a flow chart illustrating an example process for generating an abstract configuration using a topology compiler, according to techniques of this disclosure.

[0027] Figure 10 is a flow chart illustrating an example process for configuring device resources using a topology compiler, according to techniques of this disclosure. DETAILED DESCRIPTION

[0028] Figure 1is a block diagram illustrating an example of elements of an enterprise network 2 that is managed using a controller device 10. The managed elements 14A through 14G of the enterprise network 2 (collectively referred to as "elements 14") include network devices that are interconnected via communication links to form a communication topology for exchanging resources and information. Elements 14 (also generally referred to as network devices or remote network devices) 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 combinations of such devices. Although described in this disclosure as transmitting, delivering, or otherwise supporting packets, the enterprise network 2 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). The communication links interconnecting the elements 14 may be physical links (e.g., optical links, copper links, etc.), wireless links, or any combination thereof.

[0029] Enterprise network 2 is shown coupled to a public network 18 (e.g., the Internet) via a communication link. For example, public network 18 may include one or more client computing devices. Public network 18 may provide access to web servers, application servers, public databases, media servers, end-user devices, and other types of network resources and content.

[0030] The controller device 10 is communicatively coupled to the element 14 via the enterprise network 2. In some examples, the controller device 10 forms part of a device management system, although in Figure 1 Only one device of the device management system is shown for illustrative purposes. The controller device 10 can be coupled directly or indirectly to the various elements 14. Once the elements 14 are deployed and activated, the administrator 12 uses the controller device 10 to manage the network devices using a device management protocol. One example device protocol is the Simple Network Management Protocol (SNMP), which allows the controller device 10 to traverse and modify the Management Information Base (MIB) that stores configuration data within each of the managed elements 14. More details of the SNMP protocol can be found in: Harrington et al., RFC 3411, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", Network Working Group, Internet Engineering Task Force Draft, December 2002, which is available at http: / / tools.ietf.org / html / rfc3411, the entire contents of which are incorporated herein by reference.

[0031] Controller device 10, also known as a network management system (NMS) or NMS device, and elements 14 are centrally maintained by the enterprise's IT group. Administrator 12 interacts with controller device 10 to remotely monitor and configure elements 14. For example, administrator 12 can receive alerts from controller device 10 regarding any element 14, view configuration data for element 14, modify configuration data for element 14, add new network devices to enterprise network 2, remove existing network devices from enterprise network 2, or otherwise manipulate enterprise network 2 and the network devices therein. Although described with respect to enterprise networks, the techniques of this disclosure are also applicable to other types of networks, both public and private, including LANs, VLANs, VPNs, and the like.

[0032] In some examples, the administrator 12 uses the controller device 10 or a local workstation to interact directly with the element 14, such as through remote login, secure shell (SSH) or other such communication sessions. That is, the element 14 generally provides an interface for direct interaction, such as a command line interface (CLI), a network-based interface, a graphical user interface (GUI), etc., through which the user can interact with the device to directly issue text-based commands. For example, these interfaces typically allow the user to interact directly with the device, such as through remote login, secure shell (SSH), hypertext transfer protocol (HTTP) or other network sessions, to enter text according to a defined grammar to submit commands to the managed element. In some examples, the user uses the controller device 10 to initiate an SSH session 15 with one of the elements 14 (e.g., element 14F) to directly configure element 14F. In this way, the user can directly provide commands in a format for execution to the element 14.

[0033] In addition, the administrator 12 can also create scripts that can be submitted by the controller device 10 to any or all elements 14. For example, in addition to the CLI interface, the elements 14 also provide an interface for receiving scripts that specify commands in a scripting language. In a sense, the scripts can be output by the controller device 10 to automatically invoke corresponding remote procedure calls (RPCs) on the managed elements 14. The scripts can conform to, for example, Extensible Markup Language (XML) or another data description language.

[0034] Administrator 12 uses controller device 10 to configure element 14 to specify certain operational characteristics that further administrator 12's objectives. For example, administrator 12 may specify specific operational policies for element 14 regarding security, device accessibility, traffic engineering, quality of service (QoS), network address translation (NAT), packet filtering, packet forwarding, rate limiting, or other policies. Controller device 10 performs configuration using one or more network management protocols designed for managing configuration data within managed network elements 14, such as the SNMP protocol or the Network Configuration Protocol (NETCONF) protocol or its derivatives, such as the Juniper Device Management Interface. Generally speaking, NETCONF provides a mechanism 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 Enns, "NETCONF Configuration Protocol," Network Working Group, RFC 4741, December 2006, available at tools.ietf.org / html / rfc4741, the entire contents of which are incorporated herein by reference. The controller device 10 may establish a NETCONF session with one or more elements 14 .

[0035] The controller device 10 may be configured to accept high-level configuration data or intents from the administrator 12 (which may be expressed as structured input parameters, e.g., in accordance with YANG, as described in Bjorklund, "YANG—A Data Modeling Language for the Network Configuration Protocol (NETCONF)", Internet Engineering Task Force, RFC 6020, October 2010, available at tools.ietf.org / html / rfc6020). The controller device 10 may also be configured to output corresponding low-level device configuration data sets, such as device configuration additions, modifications, and removals. Additional details regarding an example process for translating high-level configuration information into low-level device configuration information can be found below: for example, Jiang et al., “TRANSLATING HIGH-LEVEL CONFIGURATION INSTRUCTIONS TO LOW-LEVEL DEVICE CONFIGURATION,” U.S. patent application Ser. No. 15 / 198,657, filed Jun. 30, 2016, the entire contents of which are incorporated herein by reference. This disclosure refers to the low-level device configuration generated from an intent (i.e., generated by compiling or translating the intent) as “device-level intent configuration information” or “intent configuration” to distinguish this device-level configuration from out-of-band (OOB) device-level configuration. In some examples, the controller device 10 can use YANG modeling for the intent data model and the low-level device configuration model. This data can contain relationships between YANG entities, such as list items and containers. In some examples, the controller device 10 can convert the YANG data model into a database model and convert the YANG validation into data validation. Techniques for managing network devices using a graph model for high-level configuration data are described in: “CONFIGURING AND MANAGING NETWORK DEVICESUSING PROGRAM OVERLAY ON YANG-BASED GRAPH DATABASE,” U.S. patent application Ser. No. 15 / 462,465, filed Mar. 17, 2017, the entire contents of which are incorporated herein by reference.

[0036] The controller device 10 may receive action data representing any or all create, update, and / or delete actions for the intent data model from one of the administrators 12. The controller device 10 may be configured to use the same compilation logic for each of the create, update, and delete actions applied to the graph model.

[0037] Generally speaking, a controller such as controller device 10 can use a hierarchical data model for intents, low-level data models, and resources. The hierarchical data model can be based on YANG or YAML. The hierarchical data model can be represented as a graph, as described above. The use of intents can simplify network management. Intents are declarative. To implement the intent, controller device 10 attempts to select the best resources.

[0038] In general, the controller device 10 can be configured to translate a high-level configuration (e.g., an intent received from an administrator for a plurality of managed network devices) into a low-level configuration, which may also be referred to herein as a "device-level configuration" (to be applied to the managed network devices themselves). In some cases, the controller device 10 can receive an indication of a topology and role for an element 14A and generate device-level configuration information for the element 14A. For example, the administrator 12 can select a topology and role for the element 14A and provide an intent. In some examples, the controller device 10 can generate a device-level configuration for the element 14A based on the role (e.g., spine or leaf) of the element 14A in the topology (e.g., spine and leaf topology), the topology, and the intent. In some cases, the intent provided by the administrator 12 to the controller device 10 can be associated with multiple (e.g., more than 10, more than 20, etc.) roles. As the number of roles increases, the complexity of operating the controller device increases, which may cause the administrator 12 to assign incorrect roles or topologies to resource devices, causing the controller device 10 to fail to correctly implement the intent.

[0039] According to the techniques of this disclosure, the controller device 10 can support multiple topology compilers, each of which is associated with a corresponding topology. For example, the first topology compiler can be associated with a 3-level Clos network, and the second topology compiler can be associated with a 5-level Clos network. Instead of relying on the administrator 12 to assign roles to each resource device, the topology compiler can be configured to assign rules to each resource device. In this way, the topology can be used to set up the structure with less interaction from the administrator, which can improve the reliability of the structure.

[0040] Furthermore, each element 14 in the elements can call a topology compiler assigned to that topology, rather than relying on a set of instructions for all topologies. For example, element 14A can call a level-3 Clos network topology compiler with an indication of the role of a first resource device, and the level-3 Clos network topology compiler can generate an abstract configuration for the first resource device. In this example, element 14A can generate device-level configuration information to configure element 14A to implement the intent provided by administrator 12. In this way, controller device 10 can automatically generate configuration information based on the selected topology, which can reduce the time spent configuring resource devices to implement the intent.

[0041] Furthermore, the controller device 10 may implement an "extensible framework" that allows for one or more additional topology compilers while maintaining a common framework. In this manner, the controller device 10 may be configured to support new topologies while operating existing topologies at runtime without modifying the framework for the existing topologies. For example, each of the topology compilers may include a pluggable topology compiler that is configured to conform to a standard callable by an extensible framework (e.g., an application programming interface (API) framework).

[0042] For example, the controller device 10 may receive an indication of an intent. In some examples, the intent includes data indicating an update to a data structure including a plurality of nodes representing the element 14 and a plurality of edges connecting the plurality of nodes. The controller device 10 may process the intent to select a topology compiler from a plurality of topology compilers. For example, the controller device 10 may select a topology from a plurality of topologies for the element 14 based on the intent and the connectivity information of the element 14. In this example, the controller device 10 may select a topology compiler associated with (e.g., assigned to) the selected topology.

[0043] The controller device 10 can call a topology compiler via an API framework using the role of element 14A and the indication of element 14A as input to generate abstract configuration information. In this example, the controller device 10 can configure element 14A based on the abstract configuration information. In this way, the controller device 10 can automatically generate configuration information based on the selected topology, which can reduce the time to configure resource devices to achieve the intention. In addition, the use of the API framework can include an extensible framework that can allow multiple compilers that meet the standards callable by the extensible framework to be modified at runtime, so that new topology compilers can be added and existing topology compilers can be removed. In this way, the controller device 10 can be modified at runtime, which can reduce the downtime of the network 2.

[0044] Figure 2 It shows the Figure 11 is a block diagram of an example component set of a controller device 10. In this example, the controller device 10 includes a control unit 22, a network interface 34, and a user interface 36. The network interface 34 represents a device that can communicatively couple the controller device 10 to an external device (e.g., Figure 1 1a / b / g / n or other such wireless protocols).

[0045] The control unit 22 represents any combination of hardware, software, and / or firmware for implementing the functions attributed to the control unit 22 and its component modules and elements. When the control unit 22 includes software or firmware, the control unit 22 also includes any necessary hardware for storing and executing the software or firmware, such as one or more processors or processing units. Generally speaking, the processing unit may include one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FGAs), or any other equivalent integrated or discrete logic circuits, as well as any combination of such components. In addition, the processing unit is generally implemented using fixed and / or programmable logic circuits.

[0046] The user interface 36 represents an example such as the administrator 12 ( Figure 1 ) through which a user of the controller device 10 interacts with the controller device 10, for example, to provide input and receive output. For example, the user interface 36 may represent one or more of a monitor, a keyboard, a mouse, a touch screen, a touchpad, a trackpad, a speaker, a camera, a microphone, etc. Furthermore, while the controller device 10 includes a user interface in this example, it should be understood that the administrator 12 need not interact directly with the controller device 10, but may instead access the controller device 10 remotely, for example, via the network interface 34.

[0047] In this example, the control unit 22 includes a user interface module 38, a network interface module 32, and a management module 24. The control unit 22 executes the user interface module 38 to receive input from the user interface 36 and / or provide output to the user interface 36. The control unit 22 also executes the network interface module 32 to send and receive data (e.g., packets) via the network interface 34. Likewise, the user interface module 38, the network interface module 32, and the management module 24 can be implemented as corresponding hardware units, or software or firmware, or a combination thereof.

[0048] The control unit 22 executes the management module 24 to manage various network devices, such as Figure 1 Element 14. For example, management includes the following: Figure 1 The administrator 12) receives the instructions to configure the network device, and provides the user with the ability to submit instructions to configure the network device. In this example, the management module 24 also includes a configuration module 26 and a translation module 28.

[0049] Management module 24 is configured to receive intents (e.g., high-level configuration instructions) for a managed set of network devices from a user, such as administrator 12. In some examples, management module 24 may be referred to herein as a "fabric manager." Over time, users may update configuration instructions, for example, to add new services, remove existing services, or modify existing services performed by managed devices. Intents may be constructed according to, for example, YANG. In some examples, management module 24 also provides users with the ability to submit a translation function that is executed by translation module 28 to convert intents into device-specific, low-level configuration instructions, as described below.

[0050] The controller device 10 also includes a configuration database 40. The configuration database 40 generally includes information describing the managed network devices (e.g., elements 14). For example, the configuration database 40 may include information indicating a device identifier (such as a MAC and / or IP address), a device type, a device vendor, a device class (e.g., a router, a switch, a bridge, a hub, etc.). The configuration database 40 also stores device-level configuration information based on the intent of the managed devices (e.g., elements 14) (e.g., high-level configuration information, or in some cases, both high-level and low-level configuration information).

[0051] The translation module 28, which may also be referred to herein as a "device manager," can use the configuration database 40 to determine which devices are to be managed. Based on the information in the configuration database 40, the translation module 28 determines which translation functions 30 execute high-level configuration instructions, e.g., which devices will receive low-level configuration instructions. The translation module 28 then executes each of the determined translation functions of the translation functions 30, thereby providing the high-level configuration instructions as input to the translation function and receiving low-level configuration instructions. The translation module 28 can then provide the low-level configuration instructions to the configuration module 26.

[0052] After receiving the low-level configuration instructions from translation module 28, configuration module 26 sends the low-level configuration instructions to the corresponding managed network devices to update the configuration via network interface module 32. Network interface module 32 passes the low-level configuration instructions to network interface 34. Network interface 34 forwards the low-level configuration instructions to the corresponding network devices.

[0053] Although for purposes of example, the user interface 36 is described as allowing the administrator 12 ( Figure 1 ) to interact with controller device 10, but it should be understood that other interfaces may be used in other examples. For example, controller device 10 may include a Representational State Transfer (REST) ​​client (not shown) that may serve as an interface to another device through which administrator 12 may configure controller device 10. Similarly, administrator 12 may configure element 14 by interacting with controller device 10 via a REST client.

[0054] Figure 3 301 is a conceptual diagram illustrating an example of assigning roles to elements 14 according to the techniques of this disclosure. The fabric manager 302 includes an API framework 304 (also referred to herein as "API 304"), a controller 306, which includes a fabric controller 308, topology compilers 310A to 310N (collectively referred to as "topology compilers 301"), topology validation 312, role assignment 314, and an inventory manager 316. The inventory manager 316 can access Figure 2 The configuration database 40 is used to determine connectivity information.

[0055] exist Figure 3 In the example of FIG. 3 , the fabric controller 308 can invoke the topology compiler 310A (320) using the indication of the element 14A as input. For example, the fabric controller 308 can select the topology compiler 310A from the topology compilers 310 based on an indication of an intention to change the topology associated with (e.g., assigned to) the topology compiler 310A. In this example, the fabric controller 308 can invoke the topology compiler 310A via the API 304. For example, the fabric controller 308 can invoke the topology compiler 310A via a standard callable API 304.

[0056] The topology compiler 310A may read connectivity information (e.g., link and / or wiring information) from the inventory manager 316 (316). The topology compiler 310A may validate the user-requested topology based on the provided topology type and the elements 14. For example, when executed by the fabric controller 308, the topology compiler 310A may compare the connectivity information from the inventory manager 316 with valid connectivity information for the provided topology type.

[0057] The topology compiler 310A may assign topology-specific roles to the elements 14. For example, the topology compiler 310A may include a binary that, when executed by the fabric controller 308, assigns a spine or leaf role to the element 14A based on the connectivity information. For example, when executed by the fabric controller 308, the topology compiler 310A may assign the spine role to the element 14A in response to the connectivity information indicating that the element 14A is wired as a spine in a spine and leaf topology.

[0058] Figure 4 is a conceptual diagram illustrating an example of generating an abstract device configuration 332 for a resource device according to the techniques of this disclosure. Fabric manager 302 includes API 304, controller 306 including fabric controller 308, topology compiler 310, and abstract device configuration 332.

[0059] exist Figure 4 In the example of , the fabric controller 308 can invoke a topology compiler (340) in the topology compiler 310 via the API 304 using a device resource including a role as input. For example, the fabric controller 308 can invoke the topology compiler 310A via the API 304 using an indication of an element 14A including a role (e.g., leaf or spine) as input. Based on the role and topology associated with the topology compiler 310A, the fabric controller 308, when executing the topology compiler 310A, can create an abstract device configuration 332 (342). For example, the fabric controller 308, when executing the topology compiler 310A, can create an abstract device configuration 332 for the element 14A based on the role of the element 14A. The abstract device configuration 332 can include OpenConfig instructions on a per-device basis (e.g., for each element in the element 14A).

[0060] Figure 5 is a conceptual diagram illustrating an example of generating an abstract device configuration 352 for service resources according to the techniques of this disclosure. Fabric manager 302 includes API 304, controller 306 including service controller 350, topology compiler 310, and abstract device configuration 332.

[0061] exist Figure 5In the example of FIG, the service controller 350 can utilize API 304 to call the topology compiler (360) in the topology compiler 310 using service resources including roles as input. For example, the service controller 350 can call the topology compiler 310A via API 304 using an indication of a service resource including roles as input. Based on the roles and topology associated with the topology compiler 310A, the service controller 350 can create an abstract device configuration 352 (362) when executing the topology compiler 310A. For example, the service controller 350 can create an abstract device configuration 352 for the service resource based on the role of the service resource when executing the topology compiler 310A. The abstract device configuration 352 can include OpenConfig instructions on a per-service resource basis.

[0062] Figure 6 is a conceptual diagram showing an example of generating a device level configuration according to the technology of the present disclosure. Figure 6 In some examples, the topology compiler 310 can use API 304 when converting intents to abstract device configurations. Resource controllers 372A through 372C (collectively, "resource controllers 372") can be configured for topology awareness. For example, resource controller 372A can determine the topology implemented by resource controller 372A and call a topology compiler in topology compiler 310 associated with the topology implemented by resource controller 372A. In some examples, the telemetry manager can output telemetry information to each resource controller in resource controller 372. The device manager can convert the abstract configuration to a device level configuration. In some examples, the device manager can include Figure 2 The translation module 28 and / or may be configured to perform one or more functions of the translation module 28.

[0063] The resource controller 372 may be configured to provide semantic translation of intended resources into abstract configurations based on topology. For example, the resource controller 372A may invoke the topology compiler 310A associated with the topology implemented by the resource controller 372A to translate the intended resources into abstract configurations.

[0064] The resource controller 372 can be configured to support multiple topology compilers. For example, the resource controller 372A can select one of the topology compilers 310 associated with the topology implemented by the resource controller 372A. In some examples, the topology compilers 310 can be pluggable. For example, each topology compiler in the topology compilers 310 can include a pluggable compiler that is configured to conform to a standard that can be called by the API 304. For example, the API 304 can include a communication standard set for providing intent information to the topology compiler 310, and can include a communication standard set for receiving abstract configurations. In this way, new topology compilers can be added to the topology compiler 310 at runtime.

[0065] Resource controller 372 can be topology agnostic. For example, resource controller 372A can send an abstract configuration to a device manager (e.g., translation module 28). In this example, the device manager can translate the abstraction into a device-level configuration.

[0066] exist Figure 6 In the example of FIG304 , processing circuitry (e.g., processing circuitry of controller device 10) may generate one or more change events for resource controller 372 using intent as input via API 304. For example, processing circuitry (e.g., processing circuitry of controller device 10) may generate one or more change events for resource controller 372 based on the intent and further based on a data structure (e.g., a graph model) stored in graph database 370.

[0067] The resource controller 372A can determine whether a change event has occurred for the resource controller 372A. For example, the monitoring function 305 (also referred to herein as "monitoring 305") can indicate, via the API 304, whether a change event has occurred for each of the resource controllers 372A. The resource controller 372A can determine a topology compiler from the topology compiler 310 based on one or more change events. For example, the resource controller 372A can determine the topology compiler 310A associated with the one or more change events based on a portion of a data structure stored by the graph database 370. In this example, the resource controller 372A can call the topology compiler 310A via the API 304 using the role of the element 14A and the indication of the element 14A as input to generate abstract configuration information. In this example, the topology compiler 310, when executed by a processing circuit (e.g., a processing circuit of the controller device 10), can output the abstract configuration information to the resource controller 372A.

[0068] Resource controller 372A may configure element 14A based on the abstract configuration information. Resource controller 372A may configure element 14A based on the abstract configuration. In some examples, resource controller 372A may output the abstract configuration to a device manager and may receive a device-level configuration. In some examples, resource controller 372A may determine a device-level configuration based on the abstract configuration.

[0069] Figure 7 is a block diagram illustrating an example Clos network 430. Clos network 430 includes three stages of switches: ingress switches 432A through 432N (ingress switches 432), mid-stage switches 434A through 434N (mid-stage switches 434), and egress switches 436A through 436N (egress switches 436). Although the letter "N" is used to designate a variable number of ingress switches 432, mid-stage switches 434, and egress switches 436, the number of switches included in each stage is not necessarily the same. That is, there may be different numbers of ingress switches 432, mid-stage switches 434, and egress switches 436. Furthermore, although Clos network 430 includes three stages, a general Clos network may include any number of stages (e.g., a five-stage Clos network or another level of Clos network).

[0070] Figure 8 is a flowchart illustrating an example process for determining roles for network devices using a topology compiler according to the techniques of this disclosure. In some examples, Figure 8 The process shown in may represent "Day 0" operations. The controller device 10 may receive a list of network devices (502). For example, the controller device 10 may receive Figure 1 The controller device 10 may collect connectivity information from the set of network devices (504). For example, the controller device 10 may collect wiring information from one or more elements 14.

[0071] The controller device 10 may provide a set of recommended topologies (506). For example, the controller device 10 may recommend a leaf-and-spine network topology in response to determining that the connectivity information indicates that the elements 14 are arranged in a leaf-and-spine network topology. The controller device 10 may verify the devices and connectivity information based on the recommended topology (508). For example, the controller device 10 may verify whether the cabling provides links that support the recommended topology. The controller device 10 may receive user input selecting a topology (510). For example, the controller device 10 may receive user input selecting a topology from a plurality of recommended topologies. In some examples, the controller device 10 may receive user input confirming an instruction to implement a single recommended topology.

[0072] Controller device 10 may determine a topology compiler based on the selected topology (512). For example, controller device 10 may select a topology compiler associated with (e.g., assigned to) the selected topology from a plurality of topology compilers each associated with a corresponding topology. Controller device 10 may invoke the topology compiler to determine a role for each network device (514). For example, when executing the topology compiler, controller device 10 may determine a spine role for element 14A and a leaf role for element 14B.

[0073] Figure 9 is a flowchart illustrating an example process for generating an abstract configuration using a topology compiler according to the techniques of this disclosure. In some examples, Figure 9 The process shown in FIG. 1 may represent a "Day 1+" operation. Controller device 10 may receive an intent for multiple network devices (602). For example, controller device 10 may receive the intent from administrator 12. Controller device 10 may apply a Symantec check to the intent (604). Controller device 10 may update graph database 370 based on the intent and issue an indication of a change event on monitor 305 (606).

[0074] The resource controller 372A may receive an indication of an event (608) and invoke a topology compiler using the role and device resources as input to generate an abstract configuration for the device resources (610). For example, the resource controller 372A may determine a topology compiler from the topology compiler 310 based on the change event. For example, the resource controller 372A may determine the topology compiler 310A associated with the change event based on a portion of a data structure stored by the graph database 370. In this example, the resource controller 372A may utilize the API 304 to invoke the topology compiler 310A using the role of element 14A and the indication of element 14A as input to generate abstract configuration information. In this example, the topology compiler 310, when executed by a processing circuit (e.g., a processing circuit of the controller device 10), may output the abstract configuration information to the resource controller 372A.

[0075] Resource controller 372A may configure element 14A based on the abstract configuration (612). Resource controller 372A may configure element 14A based on the abstract configuration. In some examples, resource controller 372A may output the abstract configuration to a device manager and may receive a device-level configuration. In some examples, resource controller 372A may determine a device based on the abstract configuration.

[0076] Figure 107 is a flow chart illustrating an example process for configuring device resources using a topology compiler according to the techniques of this disclosure. A controller device 10 may receive an indication of an intent (702). For example, the controller device 10 may receive the intent from an administrator 12. The intent may include data indicating an update to a data structure including a plurality of nodes representing a plurality of network devices (e.g., element 14) and a plurality of edges connecting the plurality of nodes. In some examples, the data structure may include a graph model. The plurality of edges may define relationships between the plurality of nodes.

[0077] The controller device 10 can process the intent to select a topology compiler (704) from a plurality of topology compilers. For example, the controller device 10 can select a topology from a plurality of topologies for element 14 based on the intent and the connectivity information of element 14. In this example, the controller device 10 can select a topology compiler associated with the selected topology (e.g., assigned to the selected topology). In some examples, each topology compiler in the topology compilers 310 is associated with a corresponding topology in the plurality of topologies. For example, topology compiler 310A can be assigned to a first topology, topology compiler 310B can be assigned to a second topology, and so on. The plurality of topologies can include one or more of a 3-level Clos network topology, a 5-level Clos network topology, or a spine and leaf topology. In some examples, each topology compiler in the topology compilers includes a binary file executable by the controller device 10.

[0078] Each of the plurality of topology compilers may include a pluggable compiler configured to conform to a standard callable by the API framework. For example, each of the topology compilers 310 may include a pluggable topology compiler configured to conform to a standard callable by the API 304. For example, the API 304 may include a communication standard set for providing intent information to the topology compiler 310, and may include a communication standard set for receiving an abstract configuration.

[0079] The controller device 10 may invoke the selected topology compiler via the API using the role of the network device and the indication of the network device as input to generate abstract configuration information (708). For example, the resource controller 372A may utilize the API 304 to invoke the topology compiler 310A using the role of the network device 14A and the indication of the network device 14A as input, and the topology compiler 310A, when executed by the controller device 10, generates abstract configuration information. The controller device 10 may configure the network device based on the abstract configuration information (710). For example, the resource controller 372A may output the abstract configuration to the device manager and may receive a device-level configuration. In this example, the resource controller 372A may configure the element 14A using the device-level configuration received from the device manager. In some examples, the resource controller 372A may determine the device based on the abstract configuration and configure the element 14A using the device-level configuration determined by the resource controller 372A.

[0080] In some examples, the controller device 10 can determine the role of the network device. For example, the controller device 10 can receive instructions for multiple network devices (e.g., element 14). In this example, the controller device 10 can determine connectivity information (e.g., wiring information) for the multiple devices. The controller device 10 can select a topology for the multiple network devices based on the connectivity information. A topology compiler (e.g., topology compiler 310A) can be associated with the selected topology. The controller device 10 can call the topology compiler using the connectivity information as input via an API framework (e.g., API 304) to determine the role of the network device. In some examples, calling the topology compiler to determine the role of the network device is in response to a user interaction indicating confirmation of the selected topology.

[0081] The techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware, or any combination thereof. For example, various aspects of the described techniques may be implemented within one or more processors, including one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FGAs), or any other equivalent integrated or discrete logic circuits, and any combination of these components. The terms "processor" or "processing circuitry" may generally refer to any of the aforementioned logic circuits, alone or in combination with other logic circuits, or any other equivalent circuits. A control unit comprising hardware may also perform one or more techniques of the present disclosure.

[0082] Such hardware, software, and firmware may be implemented within the same device or within separate devices to support the various operations and functions described in this disclosure. Furthermore, any described units, modules, or components may be implemented together or separately as discrete but interoperable logic devices. Depicting different features as modules or units is intended to highlight different functional aspects and does not necessarily mean that such modules or units must be implemented by separate hardware or software components. Rather, the functions associated with one or more modules or units may be performed by separate hardware or software components, or integrated within common or separate hardware or software components.

[0083] The technology described in the present disclosure can also be implemented or encoded in a computer-readable medium (such as a computer-readable storage medium) containing instructions. The instructions embedded or encoded in the computer-readable medium can cause a programmable processor or other processor to perform the method, for example, when the instructions are executed. The computer-readable medium can include non-transient computer-readable storage media and transient communication media. Tangible and non-transient computer-readable storage media can include random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, hard disk, CD-ROM, floppy disk, cassette, magnetic media, optical media or other computer-readable storage media. The term "computer-readable storage medium" refers to a physical storage medium, rather than a signal, carrier wave or other transient medium.

[0084] Various examples have been described. These and other examples are within the scope of the following claims.

Claims

1. A method for network management, comprising: Receiving, by a controller device managing a plurality of network devices via an application programming interface (API) framework, an indication of an intent, wherein the intent includes data indicating an update to a data structure including a plurality of nodes representing the plurality of network devices and a plurality of edges connecting the plurality of nodes; processing, by the controller device, the intent to select a topology compiler from a plurality of topology compilers, the topology compiler being configured to generate abstract configuration information for each of a plurality of roles of a topology assigned to the topology compiler, wherein each of the plurality of topology compilers comprises a pluggable compiler configured to conform to a standard callable by the API framework, the API framework comprising a first set of communication standards for providing intent information to the plurality of topology compilers, and a second set of communication standards for receiving the abstract configuration information; Invoking, by the controller device via the API framework, the selected topology compiler using input indicating both a role of a network device among the plurality of network devices and the network device, so that the selected topology compiler generates the abstract configuration information; as well as The network device is configured by the controller device based on the abstract configuration information.

2. The method according to claim 1, further comprising: receiving, by the controller device, indications of the plurality of network devices; determining, by the controller device, connectivity information for the plurality of devices; selecting, by the controller device, a topology for the plurality of network devices based on the connectivity information, wherein the selected topology compiler is associated with the selected topology; as well as The selected topology compiler is called by the controller device via the API framework using the connectivity information as input to determine the role of the network device.

3. The method according to claim 2, wherein: The selected topology compiler is invoked to determine the role of the network device in response to a user interaction indicating confirmation of the selected topology.

4. The method according to any one of claims 1 to 2, wherein Configuring the network device includes determining a device-level configuration for the network device based on the abstract configuration, and outputting an indication of the device-level configuration to the network device.

5. The method according to any one of claims 1 to 2, wherein Each topology compiler of the plurality of topology compilers is associated with a corresponding topology of the plurality of topologies.

6. The method according to claim 5, wherein: The plurality of topologies include one or more of a 3-level Clos network topology, a 5-level Clos network topology, or a spine and leaf topology.

7. The method according to any one of claims 1 to 2, wherein: The plurality of edges define relationships between the plurality of nodes.

8. The method according to any one of claims 1 to 2, wherein The data structure includes a graph model.

9. The method according to any one of claims 1 to 2, wherein: Each topology compiler of the plurality of topology compilers includes a binary file executable by the controller device.

10. The method according to any one of claims 1 to 2, wherein: The network device includes one or more devices among resource devices or service devices.

11. The method according to claim 1, wherein the plurality of roles include spine roles and leaf roles; and The calling of the selected topology compiler comprises: The topology compiler is invoked with the input indicating one of the spine role or the leaf role.

12. A controller device that manages a plurality of network devices, the controller device comprising one or more processing units implemented in a circuit and configured to: receiving, via an application programming interface (API) framework, an indication of an intent, wherein the intent includes data indicating an update to a data structure including a plurality of nodes representing the plurality of network devices and a plurality of edges connecting the plurality of nodes; processing the intent to select a topology compiler from a plurality of topology compilers, the topology compiler being configured to generate abstract configuration information for each of a plurality of roles of a topology assigned to the topology compiler, wherein each of the plurality of topology compilers comprises a pluggable compiler configured to conform to a standard callable by the API framework, the API framework comprising a first set of communication standards for providing intent information to the plurality of topology compilers, and a second set of communication standards for receiving abstract configuration information; invoking the selected topology compiler via the API framework with input indicating both a role of a network device among the plurality of network devices and the network device, so that the selected topology compiler generates abstract configuration information; as well as The network device is configured based on the abstract configuration information.

13. The controller device according to claim 12, wherein: The one or more processing units are further configured to: receiving indications of the plurality of network devices; determining connectivity information for the plurality of devices; selecting a topology for the plurality of network devices based on the connectivity information, wherein the selected topology compiler is associated with the selected topology; as well as The selected topology compiler is called via the API framework using the connectivity information as input to determine the role of the network device.

14. The controller device according to claim 13, wherein: The one or more processing units are configured to, in response to a user interaction indicating confirmation of the selected topology, invoke the selected topology compiler to determine the role of the network device.

15. The controller device according to any one of claims 12 to 13, wherein: To configure the network device, the one or more processing units are configured to determine a device-level configuration for the network device based on the abstract configuration, and output an indication of the device-level configuration to the network device.

16. The controller device according to any one of claims 12 to 13, wherein each topology compiler of the plurality of topology compilers is associated with a respective topology of the plurality of topologies.

17. The controller device according to claim 16, wherein: The plurality of topologies include one or more of a 3-level Clos network topology, a 5-level Clos network topology, or a spine and leaf topology.

18. A controller device according to any one of claims 12 to 13, wherein: The plurality of edges define relationships between the plurality of nodes.

19. The controller device according to claim 12, wherein the plurality of roles include spine roles and leaf roles; and The calling of the selected topology compiler comprises: The topology compiler is invoked with the input indicating one of the spine role or the leaf role.

20. A computer-readable storage medium having stored thereon instructions that, when executed, cause a processor of a controller device that manages a plurality of network devices to: receiving, via an application programming interface (API) framework, an indication of an intent, wherein the intent includes data indicating an update to a data structure including a plurality of nodes representing the plurality of network devices and a plurality of edges connecting the plurality of nodes; processing the intent to select a topology compiler from a plurality of topology compilers, the topology compiler being configured to generate abstract configuration information for each of a plurality of roles of a topology assigned to the topology compiler, wherein each of the plurality of topology compilers comprises a pluggable compiler configured to conform to a standard callable by the API framework, the API framework comprising a first set of communication standards for providing intent information to the plurality of topology compilers, and a second set of communication standards for receiving abstract configuration information; invoking the selected topology compiler via the API framework with input indicating both a role of a network device among the plurality of network devices and the network device, so that the selected topology compiler generates abstract configuration information; as well as The network device is configured based on the abstract configuration information.

Images