Patent ID: 12210861

DETAILED DESCRIPTION

FIG.1is a block diagram illustrating an example including elements of an enterprise network2that are managed using a controller device10, in accordance with one or more techniques of this disclosure. Managed elements14A-14G (collectively, “elements14”) of enterprise network2include network devices interconnected via communication links to form a communication topology to exchange resources and information. Elements14(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 a combination of such devices. While described in this disclosure as transmitting, conveying, or otherwise supporting packets, enterprise network2may 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 elements14may be physical links (e.g., optical, copper, and the like), wireless, or any combination thereof. Enterprise network2may include many more elements14than shown inFIG.1.

Enterprise network2is shown coupled to public network18(e.g., the Internet) via communication link16. Public network18may include, for example, one or more client computing devices. Public network18may provide access to web servers, application servers, public databases, media servers, end-user devices, and other types of network resource devices and content. Although described for purposes of example with respect to an enterprise service network, the techniques of this disclosure are applicable to other types of networks, such as a branch network, a data center network, a service provider network, an Internet Service Provider network, or other type of network.

Controller device10is communicatively coupled to elements14via enterprise network2. Controller device10, in some examples, forms part of a device management system, although only one device of the device management system is illustrated for purpose of example inFIG.1. Controller device10may be coupled either directly or indirectly to the various elements14. Once elements14are deployed and activated, administrator12uses controller device10to manage the network devices using a device management protocol. One example device protocol is the Simple Network Management Protocol (SNMP) that allows controller device10to traverse and modify management information bases (MIBs) that store configuration data within each of managed elements14.

In common practice, controller device10, also referred to as a network management system (NMS) or NMS device, and elements14are centrally maintained by an Information Technology (IT) group of the enterprise. Administrator12interacts with controller device10to remotely monitor and configure elements14. For example, administrator12may receive alerts from controller device10regarding any of elements14, view configuration data of elements14, modify the configurations data of elements14, add new network devices to enterprise network2, remove existing network devices from enterprise network2, or otherwise manipulate the enterprise network2and 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.

In some examples, administrator12uses controller device10or a local workstation to interact directly with elements14, e.g., through telnet, secure shell (SSH), or other such communication sessions. That is, elements14generally provide interfaces for direct interaction, such as command line interfaces (CLIs), web-based interfaces, graphical user interfaces (GUIs), or the like, by which a user can interact with the devices to directly issue text-based commands. For example, these interfaces typically allow a user to interact directly with the device, e.g., through a telnet, secure shell (SSH), hypertext transfer protocol (HTTP), or other network session, to enter text in accordance with a defined syntax to submit commands to the managed element. In some examples, the user initiates an SSH session15with one of elements14, e.g., element14F, using controller device10, to directly configure element14F. In this manner, a user can provide commands in a format for execution directly to elements14.

Further, administrator12can also create scripts that can be submitted by controller device10to any or all of elements14. For example, in addition to a CLI interface, elements14also provide interfaces for receiving scripts that specify the commands in accordance with a scripting language. In a sense, the scripts may be output by controller device10to automatically invoke corresponding remote procedure calls (RPCs) on the managed elements14. The scripts may conform to, e.g., extensible markup language (XML) or another data description language.

Administrator12uses controller device10to configure elements14to specify certain operational characteristics that further the objectives of administrator12. For example, administrator12may specify, for an element14, 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. Controller device10uses one or more network management protocols designed for management of configuration data within managed network elements14, such as the SNMP protocol or the Network Configuration Protocol (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 Enns, “NETCONF Configuration Protocol,” Network Working Group, RFC 4741, December 2006, available at tools.ietf.org/html/rfc4741. Controller device10may establish NETCONF sessions with one or more of elements14.

Controller device10may be configured to accept high-level configuration data, or intents, from administrator12(which may be expressed as structured input parameters, e.g., according to the Yet Another Next Generation (YANG) language, which is 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). Controller device10may also be configured to output respective sets of low-level device configuration data, e.g., device configuration additions, modifications, and removals.

In some examples, controller device10may use YANG modeling for an intent data model and low-level device configuration models. This data may contain relations across YANG entities, such as list items and containers. In some examples, controller device10may convert a YANG data model into a database model, and convert YANG validations into data validations.

Controller device10may receive data from administrator12representing any or all of create, update, and/or delete actions with respect to the intent data model. Controller device10may be configured to use the same compilation logic for each of create, update, and delete as applied to the graph model.

To upgrade network devices, such as elements14, the first step is to pull the image required for upgrade. The techniques of this disclosure are different than an approach in which only a centralized device hosts the software upgrade image, either an on-premises element or Software-as-a-Service (SaaS)-based management solution, where the image to be upgraded is stored in centralized server and accessed via a common link. For data center scenarios in which there are high number of devices with high number of simultaneous pulls, a centralized approach may result in a bottleneck, leading to a larger maintenance time window. Additionally, if the image is being pulled over a WAN network this process can be quite time consuming, depending on speed and number of simultaneous pulls. This disclosure presents an image distribution approach to avoid the simultaneous pulls of the software upgrade image by multiple network devices, such as elements14, that can result in choked network or server hosting the image.

In some examples in accordance with techniques of this disclosure, controller device10may receive, such as from an administrator or other user, upgrade request11. Upgrade request11may include, for example, a command indicating an intent to upgrade the software of elements14from a software release “A” to a new or updated software release “B.” The software of an element14may include an image. An image is a serialized copy of the state of a computer system stored in some non-volatile form such as a file. Upgrade request11may indicate a software upgrade image to be used for upgrading elements14to the updated software release “B.”

In response to receiving upgrade request11, controller device10is configured to determine, e.g., based on device parameters of elements14, how to split the software upgrade image and to identify a subset of elements14to serve as image proxy devices. In some examples, controller device10selects half (fifty percent) of elements14to serve as image proxy devices. In some examples, the device parameters of elements14include an amount of storage space available on elements14that may be used to store a software upgrade image. Controller device10generates an image map indicating assignments of different portions of the software upgrade image to be stored by corresponding network devices of the selected elements14. In some examples, controller device10generates a device upgrade schedule for upgrading the elements14based on the image map.

For example, controller device10may determine a network topology of network2and may also determine device parameters associated with one or more of elements14and generate a topology graph to represent the network topology and device parameters. Controller device10may compute an optimization algorithm on the topology graph to produce the image map and device upgrade schedule that attempts to efficiently upgrade the elements14to be upgraded using a subset of the elements14to be upgraded as image proxy devices.

In some examples, controller device10selects one or more of the elements14to serve as image proxy devices that store corresponding portions of a software upgrade image, the elements14being selected from among a set of network devices to be upgraded. Controller device10generates an image map indicating assignments of different portions of the software upgrade image to be stored by corresponding network devices of the selected one or more network devices. Controller device10sends the image map to each of elements14. Controller device10sends, based on the image map, the portions of the software upgrade image to the corresponding elements14that are assigned as image proxy network devices. In some examples, elements14that are assigned as image proxy network devices are configured to, in response to receiving the image map, request their assigned portion of the software upgrade image from the controller device10, and controller device10sends the assigned portion in response to the request. Controller device10then instructs the set of network devices to initiate an upgrade process in accordance with the image map.

In general, controllers such as controller device10use 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 discussed above. Modern systems have supported intents to ease the management of networks. Intents are declarative. To realize intents, controller device10attempts to select optimal resources. Customer environments may be configured to allow customers (e.g., administrators12) to control intent realization and assure programmed intents. In some examples, controller device10may construct a graph data model by querying elements14to determine resources provided by elements14. Controller device10may generally be configured with information representing types of resources provided by each of elements14, but may query elements14to determine specific characterization data including resource information for resources matching each of the types of resources provided by elements14. Types of resources may include, for example, forwarding tables, routing tables, network access policies (e.g., for access by certain users, firewall policies, or the like), memory or other storage availability, or other such resources.

In some examples, controller device10may receive a message from an element of elements14(e.g., element14A) indicating characterizing data, such as an amount of storage space available that may be used to store a software upgrade image at element14A. In some examples, to retrieve the information indicative of the available storage capacity of element14A (or other characterization data), the controller device10may output, to element14A, a message requesting the available storage capacity of element14A. In response to the message, controller device10may receive, from element14A, information indicative of the available storage capacity of element14A. Controller device10distributes the software upgrade images to a subset of elements14in portions, and an element14that needs an upgrade can pull from the subset of elements and do the required upgrades. Controller device10does this by receiving respective characterization data for elements of a network; generating, based on the characterization data for the network devices, an image map that indicates, for each portion of a plurality of different portions of the software upgrade image, an image proxy network device selected by the control system from among the network devices to store the portion based on the characterization data. Controller device10outputs the image map to each of elements14being upgraded to cause the element to obtain each portion of the plurality of different portions of the software upgrade image from the corresponding image proxy network device selected by the control system to store the portion.

Devices such as elements14falling into the same local network are considered for image distribution to reduce the load on external communication, reducing hops to fetch image, and reducing latency. To store the image portions, the default storage system of the device is used to avoid additional overhead or change in device infrastructure. Software upgrade images could be a complete device software upgrade image, or an upgrade image for one or more software components of the device. Consider an example of fifty devices in a local network and the image size is of 2 GB. The default source may always be set to the controller device, such as controller device10, to fallback for any issues in network or during pull from any local set of devices. Since the image is split at controller device10as well, this will help to minimize the network usage because the element14will pull only the required portion. In some examples, the software upgrade image could be used in its full size if the image size can fit in the free space of the element14, and then no partitioning of the image is needed. The portions of the image could be uniform or non-uniform, depending on the free space on the devices. This free size is considered after reducing the size of the full image which will be used for actual upgrade. In some examples, the logic can be implemented as part of the existing daemon/services in the system.

For dividing the image and stitching the image portion together, in some examples a simple library function can be written. Additionally, to pull images from central or local devices instead of using SCP/FTP etc., daemons could make calls to central or establish connection to each other for transferring. This may help in reducing overhead of new services spawned in the device.

In addition, for “greenfield” cases where the device may not yet be configured to access the Internet as soon as it is plugged in, the approach described herein that provides for locally distributing the software upgrade image would be useful.

The techniques of this disclosure enable controller device10to download the software upgrade image into network2(e.g., data center) once, then using characterization data such as size, bandwidth, and a topology-aware approach to select managed devices (elements14) to host the software upgrade image. Controller device10creates an image map of image proxy devices and distributes the image map into the managed devices for other managed devices to pull from during image upgrade cycle. This helps in reducing the stress on WAN link to download same image from external sources, and also increases parallel image pulls for faster delivery of images to all devices. Additionally, the techniques of the disclosure may enable creating policies on controller device10to control the retry and working thresholds of the devices being upgraded to avoid bottlenecks.

FIG.2is a block diagram illustrating an example set of components for controller device10ofFIG.1, in accordance with one or more techniques of this disclosure. In this example, controller device10includes control unit22, network interface34, user interface36, and memory40. Control unit22includes management module24, network interface module32, and user interface module38. Management module24includes configuration module26, translation module28, and device upgrade management module30. Memory40includes upgrade image42, translation functions44, and configuration database46.

Control unit22represents any combination of hardware, software, and/or firmware for implementing the functionality attributed to control unit22and its constituent modules and elements. When control unit22includes software or firmware, control unit22further includes any necessary hardware for storing and executing the software or firmware, such as one or more processors or processing units. In general, a processing unit may include one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components. Furthermore, a processing unit is generally implemented using fixed and/or programmable logic circuitry.

Network interface34represents an example interface that can communicatively couple controller device10to an external device, e.g., one of elements14ofFIG.1. Network interface34may represent a wireless and/or wired interface, e.g., an Ethernet interface or a wireless radio configured to communicate according to a wireless standard, such as one or more of the IEEE 802.11 wireless networking protocols (such as 802.11 a/b/g/n or other such wireless protocols). Controller device10may include multiple network interfaces in various examples, although only one network interface is illustrated for purposes of example. User interface36represents one or more interfaces by which a user, such as administrator12(FIG.1) interacts with controller device10, e.g., to provide input and receive output. For example, user interface36may represent one or more of a monitor, keyboard, mouse, touchscreen, touchpad, trackpad, speakers, camera, microphone, or the like. Furthermore, although in this example controller device10includes a user interface, administrator12need not directly interact with controller device10, but instead may access controller device10remotely, e.g., via network interface34.

Memory40may be configured to store information within controller device10during operation. Memory40may include a computer-readable storage medium or computer-readable storage device. In some examples, memory40includes one or more of a short-term memory or a long-term memory. Memory40may include, for example, random access memories (RAM), dynamic random-access memories (DRAM), static random-access memories (SRAM), magnetic discs, optical discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable memories (EEPROM). In some examples, memory40is used to store program instructions for execution by controller device10. Memory40may be used by software or applications running on controller device10to temporarily store information during program execution.

In this example, control unit22includes management module24, network interface module32, and user interface module38. Control unit22executes user interface module38to receive input from and/or provide output to user interface36. Control unit22also executes network interface module32to send and receive data (e.g., packets) via network interface34. Management module24, network interface module32, and user interface module38may again be implemented as respective hardware units, or in software or firmware, or a combination thereof.

Control unit22executes management module24to manage various network devices, e.g., elements14ofFIG.1. Management includes, for example, configuring the network devices according to instructions received from a user (e.g., administrator12ofFIG.1) and providing the user with the ability to submit instructions to configure the network devices. In this example, management module24further includes configuration module26and translation module28.

Management module24is configured to receive intents (e.g., high-level configuration instructions) for a set of managed network devices from a user, such as administrator12. Over time, the user may update the configuration instructions, e.g., to add new services, remove existing services, or modify existing services performed by the managed devices. The intents may be structured according to, e.g., YANG.

Memory40includes configuration database46. Configuration database46generally includes information describing managed network devices, e.g., elements14. For example, configuration database46may include information indicating device identifiers (such as media access control (MAC) and/or internet protocol (IP) addresses), device type, device vendor, devices species (e.g., router, switch, bridge, hub, etc.), or the like. Configuration database46also stores device-level configuration information based on intents (e.g., high-level configuration information, or in some cases, both high-level configuration and low-level configuration information) for the managed devices (e.g., elements14). Configuration database46may store configuration information corresponding to each element of elements14such that management module24may access configuration for any one or more of elements14. For example, management module24may access configuration information corresponding to a configuration that controller device10pushed to element14C. In addition, configuration database46may store information periodically collected from elements14, including storage capacity.

Translation module28determines which devices are managed using configuration database46. Translation module28determines which of translation functions44to execute on the high-level configuration instructions based on the information of configuration database46, e.g., which of the devices are to receive the low-level configuration instructions. Translation module28then executes each of the determined translation functions of translation functions44, providing the high-level configuration instructions to the translation functions as input and receiving low-level configuration instructions. Translation module28may then provide the low-level configuration instructions to configuration module26. In some examples, translation module28may receive one intent corresponding to a high-level configuration and translate the high-level configuration to a set of low-level configurations, each low-level configuration corresponding to a respective element of elements14. In some examples, translation module28may receive an intent corresponding to one of elements14, and translate the intent to a low-level configuration corresponding to the respective element.

After receiving the low-level configuration instructions from translation module28, configuration module26sends the low-level configuration instructions to respective managed network devices (e.g., elements14) for which configuration is to be updated via network interface module32. Network interface module32passes the low-level configuration instructions to network interface34. Network interface34forwards the low-level configuration instructions to the respective network devices.

In response to receiving the upgrade request11, configuration module26stores data from the request to configuration database46. Device upgrade management module30downloads the upgrade image from the WAN link, and stores it to upgrade image42. Device upgrade management module30generates image maps43based on characterization data received from network elements14, such as one or more of device data and topology data. Device data may include information about available storage on the device for storing upgrade images or portions thereof. Device upgrade management module30partitions an image into portions that include serialized data broken into ordered sections.

Configuration database46may also include upgrade completion state information. As device upgrade management module30receives messages from the elements14being upgraded that they have received all of the portions of the software upgrade image, stitched the image portions together, and completed their upgrades, device upgrade management module30updates the upgrade completion state information.

When multiple network devices are selected to serve as image proxy devices, device upgrade management module30may, in some examples, generate the image map by assigning each portion of the software upgrade image to multiple network devices of the plurality of network devices. In this example, the image map contains a list of the multiple network devices in an order in which the set of network devices to be upgraded should attempt to download the portion of the software upgrade image if a previous attempt fails.

Although user interface36is described for purposes of example as allowing administrator12(FIG.1) to interact with controller device10, other interfaces may be used in other examples. For example, controller device10may include a representational state transfer (REST) client (not shown) that may act as an interface to another device, by which administrator12may configure controller device10. Likewise, administrator12may configure elements14by interacting with controller device10through the REST client.

Controller device10further stores data representing resources provided by elements14(FIG.1) in configuration database46. The resources may include, for example, network services, hardware and/or software units, and tables of elements14. Thus, the resources may include, for example, network tunnels (such as label switched paths (LSPs)), virtual private networks (VPNs), virtual routing and forwarding (VRF) tables, hardware interfaces, logical interfaces, storage space, or the like. Controller device10may be configured with a playbook, which administrator12(FIG.1) can use to program the various resources. The playbook may contain a set of resource definitions, resource discovery rules, and a resource merge strategy.

In some examples, management module24is configured to receive a high-level intent file corresponding to an intended configuration for one or more elements of elements14. The high-level intent file may represent a high-level configuration. As used herein, the term “high-level configuration” refers to a configuration which can be programmed and/or altered by a user. A “low-level configuration” may refer to a configuration that a network device such as one of elements14is configured to process and implement. Translation module may translate, using the translation functions44, the high-level configuration to one or more low-level configurations, wherein each low-level configuration of the one or more low-level configurations corresponds to an element of elements14. Translation module28may send the one or more low-level configurations to configuration module26.

Device upgrade management module30selects one or more network devices to serve as image proxy devices that store one or more corresponding portions of a software upgrade image, the one or more devices being selected from among a set of network devices to be upgraded. For example, device upgrade management module30selects a device to store the image portion that can accommodate the image portion size; these devices are called image proxy network devices. Device upgrade management module30then initializes the image in the network. Device upgrade management module30triggers the image upgrade sequence to the devices. Each of the devices pull the portions of the image from image proxy devices according to image map43and stitch the portions together to create a complete image. Once all the devices have the complete image and have signaled controller device10to indicate that they have the complete image, device upgrade management module30triggers the upgrade command on the devices.

As an example, the following are the steps taken to distribute the image in the above example: Select the device to store the image portion. An example method to achieve this:1) Select devices to be upgraded on a management system (n).2) select n/2 devices which have maximum space and have reachability to all other devices selected for upgrade.3) Portion calculation (could be partial or full image):4) The minimal size available out of the selected devices in step2will be used as the portion size of the image. Number of portions is calculated using this as ImageSize/PortionSize.5) If the free space size is same as the image size, then there is no need to split the image into portions, but rather use the full image as a single unit.6) This device selection can be made using topology awareness. For example, devices sitting closer to a gateway or that are the gateways themselves could be preferred as image proxy devices to avoid clogging the devices underneath for initial image distribution.7) An empty map/table is created consisting of a default pull option which points to pull from the controller device.8) A separate initialization table is created holding the list of image proxy devices and the image portion each will hold.

For example, out of 50 devices select 25 devices to become image proxy devices.

Example 1

Assume the minimum free size is same as the image size then the controller device will maintain the list of the image proxy devices holding the image. Table 1 is an example initialization table of an image map for example 1.

TABLE 1Portion DetailsDevicesPortion1 - (start and end index ofD1, D5, D9, D13, D17, D21end in image)

Example 2

Assume the minimum free size available on a device is 500M.

Number of portions of the image=2 G/500 M=4 [Dividing 25 into 4 portions is not even, so use 24 devices]. Table 2 is an example initialization table of an image map for example 2.

TABLE 2Portion DetailsDevicesPortion1 - (start and end index ofD1, D5, D9, D13, D17, D21part in image)Portion2 - (start and end index ofD2, D6, D10, D14, D18, D22part in image)Portion3 - (start and end index ofD3, D7, D11, D15, D19, D23part in image)Portion4 - (start and end index ofD4, D8, D12, D16, D20, D24part in image)

In this manner, generating the image map can include assigning each portion of the software upgrade image to multiple network devices of the plurality of network devices, the image map containing a list of the multiple network devices in an order in which the set of network devices to be upgraded should attempt to download the portion of the software upgrade image if a previous attempt fails.

To initialize the image in the network, the following example approach may be used.1) Based on the default table discussed above, the devices are signaled to pull that specific part of the image in the following format.2) Select initial device(s) to send the image:a) For the case where the image is not split, first the initial device is signaled to pull the image.b) For the case where the image is split, first the initial devices D1, D2, D3 and D4 are signaled to pull the image.3) Once these devices confirm the successful pull, the remaining image proxy devices are triggered in parallel.a) For no slicing of the image (Example 1 above), then all other devices simply receive the list of devices to from which to pull the image.b) These devices get the following response from the controller device and based on this response the rest of the devices per Table 2 will do parallel pulls from the devices mentioned.c) Controller device10will respond with the image map of portions of images and the devices which host them.

Example

For point 3b above: Devices D5 to D24 will do parallel pulls from the devices D1 to D4, as shown in Table 3.

TABLE 3Portion DetailsDevicesPortion1 - (start and end index ofD1part in image)Portion2 - (start and end index ofD2part in image)Portion3 - (start and end index ofD3part in image)Portion4 - (start and end index ofD4part in image)

Device upgrade management module30spreads the complete image to all devices, such as by the following process: Once all the image proxy devices have the image portions, all the devices selected for upgrade are signaled to pull the image portions. The pull command triggered on devices will contact the central server (e.g., controller device10). Controller device10will respond with the image map of portions of images and the devices which host them. For example, one of Table 2 will be shared with all the devices. The triggered device will then pull the portions of the images (the number of portions could be 1 if the triggered device is dealing with a full image) from the devices in the map. If an image pull fails (e.g., either a pull of an image portion or a pull of a full image), the triggered device attempts to pull the image portion or the full image from the next device in the list. Example control policies that can be configured on elements14: If the pull from a device fails, a policy could be defined to retry N number of times. If, all retries fail, then the device attempting to pull the image or image portion may fall back to the central server that stores the software upgrade image (which may be distinct from or the same as controller device10). In some examples, the number of parallel pulls can be controlled by a threshold of the device. For example, if a new incoming pull request raises the threshold of the system by 50% in terms of CPU and Memory usage, the request will be denied. The following process outlines the flow a typical device will go through to pull the image or image portions: 1. Request the image from controller device10or a central server. Receive the image map from controller device10. For the image portions not yet pulled, do the following: for all the image proxy devices on the list, pull the image portion from the image proxy device listed first on the image map. If the image portion pull is not successful, go to the next image proxy host on the list for that same specific image portion. Proceed until the image portion is successfully pulled. However, if no more image proxy devices remain on the list, and no more retries are available, pull from the central server as a fallback. Trigger the image upgrade sequence to the devices. Once all the devices have the images and signaled the central that they have the complete image, the upgrade command is triggered on devices.

FIG.3is a flow diagram illustrating an example operation of a control system for decentralized software upgrade image distribution for network device upgrades, in accordance with one or more techniques of this disclosure. For convenience,FIG.3is described with respect to controller device10and elements14ofFIGS.1-2. However, the techniques ofFIG.3may be performed by different components of controller device10and elements14or by additional or alternative devices.

In the example ofFIG.3, controller device10receives respective characterization data for network devices of a network (305). The network may be, for example, an enterprise network, a branch network, a data center network, a service provider network, an Internet Service Provider network, or other network. The characterization data for the network devices (elements) may include, for example, one or more of information relating to a topology of the network, a distance of the network devices to a location where a full image or image portion is stored, and an amount of available data storage space on the network devices. In some examples, controller device10considers a distance from a given network device to other network devices in selecting image proxy network devices. Controller device10may generate, based on the characterization data for the network devices, an image map that indicates, for each portion of a plurality of different portions of the software upgrade image, an image proxy network device selected by the control system from among the network devices to store the portion based on the characterization data (310). Controller device10outputs the image map to an element of elements14to cause the element to obtain each portion of the plurality of different portions of the software upgrade image from the corresponding image proxy network device selected by controller device10to store the portion (315).

In some examples, controller device10instructs a network device of the set of the network devices to be upgraded to initiate an upgrade process that obtains portions of the upgrade image in accordance with the image map. In some examples, the software upgrade image is for upgrading a software component to be executed by the network device. In some examples, generating the image map includes assigning each portion of the software upgrade image to multiple network devices of the plurality of network devices, the image map containing a list of the multiple network devices in an order in which the set of network devices to be upgraded should attempt to download the portion of the software upgrade image if a previous attempt fails. In some examples, generating the image map comprises selecting a predefined proportion of the network devices to serve as image proxy network devices (e.g., 50% (half), 25%, 75%, one third, or another predefined portion), controller device10stores an indication of the predefined proportion in configuration database46, received via configuration module26. In some examples, prior to generating the image map, controller device10identifies the network devices to be upgraded from among a plurality of network devices managed by the controller device10. For example, out of a set of elements14, controller device10identifies a subset as network devices to be upgraded prior to generating the image map.

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 (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combination of such components. The term “processor” or “processing circuitry” may generally refer to any of the foregoing logic circuitry, alone or in combination with other logic circuitry, or any other equivalent circuitry. A control unit comprising hardware may also perform one or more of the techniques of this disclosure.

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. In addition, any of the described units, modules or components may be implemented together or separately as discrete but interoperable logic devices. Depiction of different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that such modules or units must be realized by separate hardware or software components. Rather, functionality 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.

The techniques described in this disclosure may also be embodied or encoded in a computer-readable medium, such as a computer-readable storage medium, containing instructions. Instructions embedded or encoded in a computer-readable medium may cause a programmable processor, or other processor, to perform the method, e.g., when the instructions are executed. Computer-readable media may include non-transitory computer-readable storage media and transient communication media. Computer readable storage media, which is tangible and non-transitory, may include random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), flash memory, a hard disk, a CD-ROM, a floppy disk, a cassette, magnetic media, optical media, or other computer-readable storage media. The term “computer-readable storage media” refers to physical storage media, and not signals, carrier waves, or other transient media.

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