WO2016072991A1

WO2016072991A1 - Determine responsiveness to a modeled change in a simulated environment

Info

Publication number: WO2016072991A1
Application number: PCT/US2014/064337
Authority: WO
Inventors: Sung Oh; Mark A TASSINARI
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2014-11-06
Filing date: 2014-11-06
Publication date: 2016-05-12

Abstract

Some examples herein disclose manipulating a parameter within a virtualized networking system to model a change to the virtualized networking system. The examples determine a responsiveness of a device based on the modeled change within the virtualized networking system.

Description

DETERMINE RESPONSIVENESS TO A MODELED CHANGE LN A SIMULATED ENVIRONMENT

BACKGROUND

[0001 ] Product testing involves a process of measuring properties and/or performance of a specific product. As such, the process may include providing a validated, stable, and useable test environment to execute test scenarios for measuring the performance of the specific product.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] In the accompanying drawings, like numerals refer to like components or blocks. The following detailed description references the drawings, wherein:

[0003] FIG. 1 is a block diagram of an example test controller to simulate an environment of a networking system for modeling a change to determine a responsiveness of a software defined networking (SDN) controller;

[0004] FIG. 2 is a block diagram of an example test controller to retrieve topology information of various networking components from a database, the test controller simulates an environment from the topology information of various networking components to manipulate parameters within the simulated environment to test a responsiveness of an SDN controller,

[0005] FIG. 3 is a flowchart of an example method executable by a controller to determine a responsiveness of a device based on a modeled change within a simulated environment;

[0006] FIG. 4 is a flowchart of an example method by a controller to simulate an environment representative of a networking system through a virtualization of the networking system and manipulating a parameter in the virtualized networking system to determine a responsiveness of a device; and

[0007] FIG. 5 is a block diagram of an example computing device with a processor to execute instructions in a machine-readable storage medium for virtualizing a networking system, manipulating a parameter within the virtualized networking system to model a change within the virtualized networking system, and determining a responsiveness of a device based on the modeled change. DETAILED DESCRIPTION

[0008] Product testing environments may be challenging as flexibility and capacity of the product testing environment may be limited. For example, if there is an increase or decrease in demand on the product, building infrastructure and capacity to support the demand change may be infeasible. In a further example, if there is an increase in the demand on the product, there may be much investment in the resources to build the testing infrastructure. These resources may sit idle if there is a decrease in the demand on the product. Additionally, the product may not be tested until deployment of the product in the actual environment. This increases costs in resources as bugs and other issues may not be worked out until encountering problems.

[0009] To address these issues, examples disclosed herein provide flexibility to a networking system for testing a specific product. The examples produce a virtualized network for testing the product or device, such as a software defined networking (SDN) controller. Network virtualization involves the process of combining hardware and software network functionality into a software-based entity, as the virtualized network. Producing the network virtualization representative of the networking system provides the flexibility for testing the SDN controller in various scenarios.

[0010] Additionally, the examples manipulate a parameter within the virtualized network to model a change. The parameters within the virtualized network represent a characteristic, factor, aspect, or element of the virtualized network which may be manipulated to model a specific change to the network. Examples of the manipulated parameter include, by way of example, varying a number of end devices, varying a number of switches, varying a number of links between the networking components, and/or adjusting a placement of the links among the networking components. The modeled change represents an event or scenario that may occur based on the manipulated parameter. The modeled change includes, by way of example, failure of a networking component, increase in demand, decrease in demand, re-routing network traffic, etc. Thus, upon modeling the change to the virtualized networking system, the SDN controller is tested to determine how the SDN controller may respond to the modeled change. Testing the behavior of the SDN controller enables the networking system to test whether the SDN controller is capable of handling various scenarios in the simulated environment. Further, determining the responsiveness of the SDN controller, allows an administrator to respond to production level within the virtualized network without a corresponding increase in test investment resources. Additionally, this allows the test capacity to increase in a short term basis to predict how the SDN controller may behave prior to deployment in the actual environment.

[0011] In summary, examples disclosed herein provide a flexible mechanism to test behavior of a device (e.g., an SDN controller) prior to deployment in an actual networking system. The examples produce a virtualized network representative of the actual networking system and manipulate a parameter within the virtualized network for modeling a scenario. Manipulating the parameter within the virtualized network provides an implementation for modeling the change and testing the behavior of the device, accordingly .

[0012] Referring now to the figures, FIG. 1 is a block diagram of an example test controller 102 to produce a simulated networking environment 110. The test controller 102 manipulates a parameter, at module 104, within the simulated networking environment 110. The simulated networking environment 110 models a change to the simulated networking environment 110 based on the manipulated parameter at module 104. A software defined networking (SDN) controller 106 responds to the modeled change within the simulated networking environment 110 and reports results of the response at module 108 to the test controller 102. Reporting the responsiveness of the SDN controller 106 to the modeled change in the simulated networking environment 110, allows the test controller 102 to test the SDN controller 106 in various scenarios to determine whether the SDN controller 106 is capable of handling such scenarios. In one implementation, FIG. 1 represents a software defined network (SDN), such that the SDN controller 106 and the simulated networking environment 110 communicate using OpenFlow communications. OpenFlow communications enables the SDN controller 106 to determine a path of networking packets over the simulated networking environment 1 10. For example, using OpenFlow, a communications protocols, gives access to a forwarding plane on a virtual and/or physical switch in the simulated networking environment 110. In other implementations, the SDN controller 106 reports the responsiveness to the test controller 102 over various communication protocols such as Representational State Transfer Application Programming Interface (RESTful API), JAVA API, or other type of custom scripts for communication.

[0013] The test controller 102 is a hardware component responsible for driving the operation and fun ctionality of the simul ated networking environment 110 to test the respon se of the S DN controll er 106. The test controller 102 serves as an orchestrator in the sense the test controller 102 provides the intelligence to produce the simulated networking environment 110 for modeling the change to test the SDN controller 106. The test controller 102 drives the networking components within the simulated networking environment 110 to determi ne the responsiveness of the SDN controller 106 to various modeled changes. Additionally, the test controller 102 may operate as a master within the networking system of FIG. 1. Operating as the master, the test controller 102 may instruct a virtual and/or physical switch within the simulated networking environment 110 how to handle networking packets for forwarding and receiving. Implementations of the test controller 102 include a processor, electronic device, computing system, microprocessor, microchip, chipset, electronic circuit, semiconductor, microcontroller, central processing unit (CPU), or other type of processing system capable of producing the simulated networking environment 110 and determining the responsiveness of the SDN controller to the modeled change.

[0014] The simulated networking environment 110 is a representation of the networking system, such as the SDN network. The simulated networking environment 110 refers to the creation of a virtual rather than actual version of the SDN networking system. As such, the simulated networking environment 110 includes the networking hardware, operating system, virtual switches, virtual machines, end devices, hosting devices, storage device, routing tables, and other networking components for use in the SDN networking system. In one implementation, the test controller 102 retrieves topology information which includes data defining connections, traffic flow patterns, and/or specifications of the various networking components to route network traffic in the simulated networking environment 110. Retrieving the topology information enables the test controller 102 to produce the simulated networking environment 110 by creating each of the various networking components and connections between these networking components. In another implementation, the simulated networking environment 110 is produced through a virtual ization of the various networking components. As such, the simulated networking environment 110 includes a set of instructions, process, operation, logic, technique, function, firmware, and/or software executable by the test controller 102 to create the simulated networking environment 110.

[0015] At module 104, the test controller 102 manipulates the parameter within the simulated networking environment 110 to model the change. The manipulated parameter is a characteristic of the simulated networking environment 110 which may be reconfigured to model the change to simulated networking environment 110. By way of example, the manipulated parameter includes varying a number of virtual components within the simulated networking environment 110, varying a number of de vices accessing the simulated networking environment 110, varying at least one connection between the various networking components, varying an operation of one of the networking components, and/or placement of a connection between the various networking components. The modeled change represents the various kinds of scenarios the simulated networking environment 1 10 may experience. By way of example, the modeled change within the simulated networking system 110 includes varying a demand in resources supported by the SDN controller 106, a failure of at least one of the networking components, reconfiguring data flow routes, etc. For example, as illustrated in FIG. 1 , the modeled change may include decreasing a number of end devices accessing the network as indicated with an "X," through the computing device. In this example, the manipulated parameter includes dropping the connections from that computing device to find out how the SDN controller 106 responds. Implementations of module 104 include by way of example, a set of instructions, process, operation, logic, technique, function, firmware, and/or software executable by the test controller 102 to manipulate the parameter within the simulated networking environment 1 10.

[0016] The SDN controller 106 is an electronic component which supports resources within the simulated networking environment 110. Such resource support, includes, by way of example, connecting an end device such as illustrated by the computing devices in FIG. 1, to the networking system. The SDN controller 106 is a hardware component which serves as support for the resources within the simulated networking environment 1 10. As such, implementations of the SDN controller 106 include a networking device, interface controller, processing device, or other type of networking controller.

[0017] At module 108, the SDN controller 106 reports the responsiveness to the modeled change within the simulated networking environment 1 10 to the test controller 102. The responsiveness includes the behavior of the SDN controller 106 in response to the modeled change in the simulated networking environment 1 10. As such, the responsiveness includes whether the SDN controller 106 is capable of handling the modeled change in the simulated networking environment 110. By way of example, the responsiveness of the SDN controller 106 includes whether the SDN controller 106 drops a data packet, handles incoming data packets in an efficient manner, provides access to requesting devices, etc. Implementations of module 108 include by way of example, a set of instructions, process, operation, logic, technique, function, firmware, and/or software executable by the SDN controller 106 to report responsiveness to the modeled change within the simulated networking environment 110. [0018] FIG. 2 is a block diagram which illustrates how multiple test controllers 102 may execute parameter manipulation within multiple simulated networking environments 110 for testing a corresponding SDN controller 106. In one implementation, the multiple test controllers 102 may simultaneously execute the parameter manipulation to model changes in each simulated networking environment 110 for testing a response of the corresponding SDN controller 106. The multiple test controllers 102 retrieve topology information from a database 214 for producing each of the simulated networking environments 110. Each of the test controllers 102 simulates the networking environments 110 from the retrieved topology of various networking components. The topology information from the database 214 includes data which defines connections, traffic flow patterns, and/or specifications of the various networking components in each of the simulated networking environmen ts 110. Upon retrieving the topology information from the database 214, each of the test controllers 102 may communicate the topology information to each switch control 216 and each end device control 220. The multiple switch controls 216 and the multiple end device controls 220 manage and may produce from the topology information retrieved by the multiple test controllers 102, the various networking components within each of the simulated networking environments 110. These various networking components in each of the simulated networking environments 110 include components such as multiple virtual switches 218 and virtualized end devices 222. For example, the multiple switch controls 216 manage and may produce or create the multiple virtual switches 218 within the simulated networking environments 110. In another example, the end device controls 220 manage and may produce or create the multiple virtualized end devices 222.

[0019] The database 214 maintains topology information in which the multiple test controllers 102 retri eve to produce each of the simulated networking environments 110. In one implemen tation, upon receiving the responsiveness for the SDN controller 106, the test controller 102 compiles these results for storage in the database 214. As such, implementations of the database 214 include a hardware component or combination of hardware components in which data may be stored and maintained.

[0020] The swi tch control 216 manages and as such may produce the virilization of each of the virtual switches 218. Additionally, the switch controls 216 manipulate the parameters within the simulated networking environments 110. Such parameter manipulation may include, by way of example, varying a number of virtual switches 218, a number of links or connections between the virtual switches 218, and/or placement of the links supported by the SDN controller 106. Thus, the switch control 216 manipulates various parameters to model various changes or scenarios within the simulated networking environment 1 10 to test the response of the SDN controller 106. For example, the modeled change may include a failure of a switch, thus the switch control 216 may sever connections to the specific failed switch to test how the SDN controller 106 handles the modeled change. In implementations, the switch control 216 may include a hardware component and by way of example, includes a processor, electronic device, microchip, chipset, electronic circuit, semiconductor, and/or microcontroller. In other implementations, the switch control 216 includes a virtualized component and by way of example, may include a set of instructions, process, operation, logic, technique, function, firmware, and/or software executable by the test controller 102 to produce the each of the multiple virtual switches 218.

[0021] The multiple virtual switches 218 represent virtualized components in the simulated networking environments 110 which provides a form of packet switching by forwarding network traffic to the appropriate destination device. Each of the multiple virtual switches 218 processes networking traffic (e.g., packet(s)) and forwards the networking traffic accordingly. The retrieved topology information includes specification information regarding the power, network interconnections, etc. Thus, the test controller 102 and/or switch control 216 produces each of the virtualized switches 218. For example, each of the multiple virtual switches 218 includes the power, console, and network interconnections. The power simulates the amount of power consumed by each of the networking switches, the console provides an operating system of the respective virtual switch, and the network interconnections provides the connections between the respective virtual switch and other networking components in the simulated networking environment 110. Although FIG. 2 represents each of the multiple virtual switches 218 with power, console, and network interconnect, limitations should not be limited as each of the multiple virtual switches may include a control plane specifying the forwarding instructions for networking traffic and/or a data plane for forwarding the networking traffic accordingly. Additionally, FIG. 2 represents multiple virtual switches 218, but may include a single virtual switch 218, etc.

[0022] The end device control 220 manages and as such may produce the virtual ization of each of the virtualized end devices 222. The end device control 220 may manipulate the parameters within the simulated networking environment 110 by varying a number of the virtual ized end devices 222. In this manner, the end device control 220 manipulates the parameter to model the change, such as an increase and/or decrease in the demand of virtualized end devices 222 accessing the networking system through the SDN controller 106. For example, the end device control 220 increases the number of virtualized end devices 222 supported by respective SDN controller 106 to represent an increased demand. In implementations, the end device control 220 may include a hardware component and as such may include a processor, electronic device, microchip, chipset, electronic circuit, semiconductor, microcontroller. In other implementations, the end device control 220 may include a virtualized component for managing each of the virtualized end devices 222 and may include a set of instructions, process, operation, logic, technique, function, firmware, and/or software executable by the test controller 102 and/or end device control 220 to produce the each of the multiple virtualized end devices 222.

[0023] The virtualized end devices 222 are virtual machines produced to represent the computing devices which may access the networking system in the simulated networking environment 110. Each of the virtualized end devices 222 include power and console for virtualizing the amount of power consumed by each of the virtualized end devices 222 and representin g a combination of inputs into each of the virtualized end device 222. For example, the console may represent the combination of a keyboard and display for user interface. This provides an additional level of granularity the test controller 102 may tweak for manipulation and determining the responsiveness of the SDN controller 106. The virtualized end devices 222 form the interface between the human network and the underlying networking system. As such, the virtualized end devices 222 represent computing devices which may include, by way of example, laptops, computers, file servers, web servers, printers, mobile devices, security cameras, or other type of computing devices. Additionally, although FIG. 2 illustrates multiple virtualized end devices 222, implementations should not be limited as this was done for illustration purposes. For example, the simulated networking environment 110 may include a single virtualized end device 222.

[0024] FIG. 3 is flowchart of an example method, executable by a controller, to determine a responsiveness of a device to a modeled change within a simulated environment. The controller simulates the environment representative of a networking system and proceeds to manipulate a parameter within the simulated environment. Manipulating the parameter within the simulated environment enables the controller to model the change within the simulated environment to determine how the device will respond to the modeled change. Determining how the device will respond to the modeled change enables the controller to test whether the device is capable ofhandling various scenarios in the simulated environment. Testing the device capability in the simulated environment allows the controller to implement the device prior to investing in resources for the deployment of the devi ce. In implemen tations, the device being tested for responsiveness i ncludes an SDN controller in an SDN networking system. As such, the term SDN controller and device may be used interchangeably through the discussion of FIG. 3. In discussing FIG. 3, references may be made to the components in FIGS. 1-2 to provide contextual examples. In one implementation, the test controller 102 and 202 as in FIGS. 1-2 executes operations 302-306 to determine the responsiveness of the device to the modeled change in the simulated environment. In another implementation, a networking device, such as a switch executes operations 302-306 to determine the responsiveness of the device to the modeled change within the simulated environment. Further, although FIG. 3 is described as implemented by a controller, it may be executed on other suitable components. For example, FIG. 3 may be implemented in the form of executable instructions on a machine-readable storage medium 504 as in FIG. 5.

[0025] At operation 302, the controller simulates the environment representative of the networking system. In one implementation, the controller simulates the environment by producing a virtualization of the networking system. In this implementation, the controller virtualizes the SDN networking system to simulate various scenarios for testing how the SDN controller may respond within the networking system. Simulating the environment includes obtaining topology information defining connections between the various networking components within the simulated environment.

[0026] At operation 304, the controller models the change to the simulated environment representative of the networking system through the manipulation of at least one parameter. The modeled change represents the various kinds of scenarios the SDN controller may experience within the networking system. By way of example, modeling the change within the simulated networking system may include varying a demand in the resources supported by the SDN controller. In this example, the manipulated parameter may include varying a number of virtual switches in which the SDN controller communications with, varying a number of end devices access the networking system, etc. In other examples, the modeled change may include varying a number of packets which are forwarded and/or received. The manipulated parameter in this example may include instructions to the SDN controller on how to handle the varying number of packets. In one implementation, an administrator may upload a test script which is an internal mechanism that specifies the manipulated parameter. For example, the test script may create connections and/or behaviors among the various networking components to analyze the behavior of the SDN controller. In this implementation, the specific modeled change may be defined within a database. Thus, the controller may retrieve the test case specific to the modeled change for collecting scripts and executing these scripts to manipulate the parameter within the simulated environment. In this manner, the controller may recreate the specific modeled change with the manipulated parameters to test how the SDN controller performs upon modeling the change multiple times or over a period of time.

[0027] At operation 306, the controller determines the responsiveness of the SDN controller to the modeled change at operation 304. The responsiveness is how the SDN controller respond the modeled change. By way of example, the responsiveness includes the behavior of the SDN controller, such as whether the SDN controller drops a packet, handles incoming packets in an efficient manner, provides access to requesting devices, etc. As such, the controller may track the number of packets processed by the SDN controller, a number of virtual physical switches in which the SDN controller may communicate, and/or a number of devices accessing the simulated environment, etc. In one implementation, the SDN controller reports to the networking device how it responds to the modeled change. In another implementation, the controller monitors the behavior of the SDN controller to determine if the SDN controller is capable of handling the modeled change to the simulated environment.

[0028] FIG. 4 is a flowchart of an example method, executable by a controller, to simulate an environment representative of a networking system. The simulation of the environment may occur by producing a virtual izing of the networking system and defining a topology of interconnections between various networking components within the networking system. The controller may proceed to model a change to the virtualized networking system by manipulating a parameter within the virtualized networking system. In one implementation, the controller manipulates the parameter by varying a number of virtual devices supported by a device, such as an SDN controller. The modeled change represents an event to the networking system while the parameter manipulation includes tweaks to those networking components to represent the event. For example, to model an increase in end devices within the networking system, the controller increases a number of devices which are supported by the networking system. Upon modeling the change to the virtualized networking system, the controller determines a responsiveness of a device to the modeled change. In implementations, the device being tested for responsiveness includes an SDN controller in an SDN type of networking system. As such, the term SDN controller and device may be used interchangeably through the discussion of FIG. 4. Determining the responsiveness of the SDN controller, the controller tests how the SDN controller behaves for the modeled change in the networking system. Upon determining the responsiveness of the SDN controller, the controller manipulates a different parameter to model and different change and determines the responsiveness of the SDN controller to the different modeled change. Manipulating various parameters to model various changes in the virtualized networking system provides a flexibility to test how the SDN controller may respond to various modeled changes, in discussing FIG. 4, references may be made to the components in FIGS. 1-2 to provide contextual examples. In one implementation, the test controller 102 and 202 as in FIGS. 1-2 executes operations 402-416 to determine the responsiveness of the device to the modeled change in the virtualized networking system. In another implementation, a networking device such as a switch executes operations 402-416 to determine the responsiveness of the device to the modeled change within the virtualized networking system. Further, although FIG.4 is described as implemented by a controller, it may be executed on other suitable components. For example, FIG. 4 may be implemented in the form of executable instructions on a machine-readable storage medium 504 as in FIG. 5.

[0029] At operation 402, the controller simulates the environment representative of the networking system. In one implementation, the controller simulates the environment through producing a virtualization of the networking system as at operation 404. Operation 402 includes simulating an SDN networking system to test the SDN controller within this system. Operation 402 may be similar in functionality to operation 302 as in FIG. 3.

[0030] At operation 404, the controller produces the virtualization of the networking system. By way of example, the modeled change may be specified as input for the controller to retrieve the corresponding data. In this implementation, the modeled change is considered a type of test profile to perform a specific test to validate how the SDN controller behaves within a specific scenario. In one implementation, the controller retrieves the topology of the various networking components for producing the virtualized networking system as at operation 406.

[0031] At operation 406, the controller defines the topology of the various networking components within the networking system. The topology information includes data which defines the connections, traffic flow patterns, and/or specifications of the various networking components within the virtualized networking system. In this manner, the controller may reproduce a customer environment to validate the SDN controller prior to implementation within the customer environment. The controller may retrieve the topology information from a database which is specific to each change which should be modeled for testing the SDN controller, In another implementation, the topology information may be transmitted from the database to the controller.

[0032] At operation 408, the controller models the change within the virtualized networking system. Operation 408 includes manipulating at least one of the parameters within the virtualized networking system. The parameters within the virtualized networking system include a characteristic, factor, aspect, or element of the networking system which may be manipulated to model a specific change to the virtualized networking system. For example, the parameter may include disabling an interconnection between components to model a failure of a particular component within the virtualized networking system. In other examples, the parameter may include varying a number of virtual networking components, a number of links, placement of links supported by the SDN controller, etc. in a specific implementation, the manipulated parameter may include varying the number of virtual devices supported by the SDN controller as at operation 410. Operation 408 may be similar in functionality to operation 304 as in FIG. 3.

[0033] At operation 410, the controller varies the number of virtual devices supported by the SDN controller. Varying the number of virtual devices includes increasing or decreasing the number of virtual devices in which the SDN controller supports.

[0034] A t operation 412, the controller determin es th e respon si veness of the SDN controller to the modeled change within the virtualized networking system. The SDN controller may transmit a report to the controller which describes the functionality and operation of the SDN controller in response to the modeled change. As such, the controller may determine how the SDN controller responds to the specific modeled change to determine whether the SDN controller has the capability of handling the specific modeled change. If the controller determines the SDN controller is unable to handle the specific modeled change, then an administrator may change infrastructure or other design elements and re-test the SDN controller as at operations 414-416. In implementations, the SDN controller communicates responsiveness to the controller using Representational state transfer (RESTful) Application Programming Interface (API), JAVA API, or other type of custom scripts for communication. Operation 412 may be similar in functionality to operation 306 as in FIG. 3.

[0035] At operation 414, the controller manipulates another parameter different from the manipulated parameter at operations 408-410. Manipulating a different parameter, the controller can test the SDN controller for a different modeled change within the virtualized networking system. For example, the first manipulated parameter may include increasing the number of devices to model the change of how the SDN controller may handle in increase in demand of devices accessing the networking system, in this example, the second manipulated parameter may include decreasing the number of devices to model the change of a decrease in demand of devices accessing the networking system.

[0036] At operation 416, the controller determines the responsiveness of the SDN controller to the different modeled change. Manipulating the different parameter at operation 414 to model the different change enables the controller to test the various scenarios in the virtualized networking system in a flexible manner without in vesting in the testing infrastructure for deployment of the S DN controller. This also allows the controller to respond to production issues based on the responsiveness of the SDN controller to the various scenarios.

[0037] FIG. 5 is a block diagram of computing device 500 with a processor 502 to execute instructions 506-518 within a machine-readable storage medium 504. Specifically, the computing device 500 with the processor 502 is to virtualize a networking system manipulate a parameter within the virtualized networking system. Manipulating the parameter within the virtualized networking system enables the virtualized networking system to model a change to the system. Based on the modeled change to the virtualized networking system, the computing device 500 is to determine a responsiveness of a device, such as an SDN controller, to the modeled change. Although the computing device 500 includes processor 502 and machine-readable storage medium 504, it may also include other components that would be suitable to one skilled in the art. For example, the computing device 500 may include the test controller 102 as in FIG. 1. The computing device 500 is an electronic device with the processor 502 capable of executing instructions 506-518, and as such embodiments of the computing device 500 include a mobile device, client device, personal computer, desktop computer, laptop, tablet, video game console, or other type of electronic device capable of executing instructions 506-518. The instructions 506-518 may be implemented as methods, functions, operations, and other processes implemented as machine-readable instructions stored on the storage medium 504, which may be non-transitory, such as hardware storage devices (e.g., random access memory (RAM), read only memory (ROM), erasable programmable ROM, electrically erasable ROM, hard drives, and flash memory).

[0038] The processor 502 may fetch, decode, and execute instructions 506-518 to determine the responsiveness of the device to the modeled change within the networking system. In one implementation, upon executing instruction 506, the processor 502 may execute instruction 508 through the execution of instruction 510. In another implementation upon executing instructions 506- 510, the processor 502 may execute instruction 512 through the execution of instruction 514. In a further implementation, upon execution of instructions 506-514, the processor 502 executes instruction 516 through the execution of instruction 518. Specifically, the processor 502 executes instructions 506-510 to: virtualize the networking system; manipulate the parameter within the networking system to model the change to the networking system; and manipulate the parameter by varying a number of virtual devices supported by the SDN controller. The processor 502 may proceed to execute instructions 512-518 to: model the change to the virtualized networking system upon the manipulation of the parameter; model the change by simulating an event to the virtualized networking system; determine the responsiveness of the device, such as the SDN controller based on the modeled change; and determine the responsiveness by determining how the device responds to the modeled change within the virtualized networking system.

[0039] The machine-readable storage medium 504 includes instructions 506-518 for the processor 502 to fetch, decode, and execute. In another embodiment, the machine-readable storage medium 504 may be an electronic, magnetic, optical, memory, storage, flash-drive, or other physical device that contains or stores executable instructions. Thus, the machine-readable storage medium 504 may include, for example, Random Access Memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage drive, a memory cache, network storage, a Compact Disc Read Only Memory (CDROM) and the like. As such, the machine-readable storage medium 504 may include an application and/or firmware which can be utilized independently and/or in conjunction with the processor 502 to fetch, decode, and/or execute instructions of the machine-readable storage medium 504. The application and/or firmware may be stored on the machine-readable storage medium 504 and/or stored on another location of the computing device 500.

[0040] In summary, examples disclosed herein provide a flexible mechanism to test a behavior of an SDN controller prior to deployment in an actual networking system. The examples produce a virtualized network representative of the actual networking system and manipulates a parameter within the virtualized network for modeling a scenario. Manipulating the parameter within the virtualized network provides an implementation for modeling the change and testing the behavior of the SDN controller, accordingly.

Claims

CLAIMS We claim :

1. A non-transitory machine-readable storage medium comprising instructions that when executed by a processing resource cause a computing device to:

manipulate a parameter within a virtualized networking system;

model a change to the virtualized networking system based on the manipulated parameter; and

determine a responsiveness of a device based on the modeled change within the virtualized networking system.

2. The non-transitory machine-readable storage medium of claim 1 comprising instructions that when executed by the processor resource cause the computing device to:

virtualize a networking system.

3. The non-transitory machine-readable storage medium of claim 1 wherein to manipulate the parameter within the virtualized networking system comprises instructions that when executed by the processor resource cause the computing device to:

vary a number of virtual devices supported by the device.

4. The non-transitory machine-readable storage medium of claim 1 wherein to model the change to the virtualized networking system based on the manipulated parameter comprises instructions that when executed by the processor resource cause the computing device to:

simulate an event to the virtualized networking system through a variance of virtual devices supported by the device.

5. The non-transitory machine-readable storage medium of claim 1 wherein to determine a responsiveness of the device based on the modeled change within the virtualized networking system comprises instructions that when executed by the processor cause the computing device to: determine how the device responds to the modeled change within the virtualized networking system.

6. A system, comprising:

a test controller to:

simulate an environment of a networking system;

manipulate a parameter within the simulated environment;

determine a responsiveness, from a software defined networking (SDN) controller, to a modeled change within the simulated environment; and

the simulated environment to model the change based on the manipulated parameter.

7. The system of claim 6 comprising:

a database to define a topology for a networking component within the simulated environment;

wherein the test controller is further to retrieve the topology for producing the simulated environment.

8. The system of claim 6 wherein the simulated environment to model the change based on the manipulated parameter comprises:

a switch control to vary at least a number of virtual switches, a number of links, and placement of the links supported by the SDN controller; and

an end device control to vary a number of virtual end devices supported by the SDN controller.

9. The system of claim 6 wherein the test controller receives results of the responsiveness from the SDN controller and determines how the SDN controller responds to the modeled change within the simulated environment.

10. The system of claim 6 wherein the test controller simulates the environment of the networking system by virtualizing the networking system.

11. A method to test a device for responsiveness, the method comprising:

simulating an environment representative of a networking system;

modeling a change within the simulated environment through a manipulation of a parameter within the simulated environment; and

determining a responsiveness of a device based on the modeled change within the simulated environment.

12. The method of claim 11 wherein simulating the environment representative of the networking system comprises:

defining a topology of multiple networking components within the networking system.

13. The method of claim 11 wherein simulating the environment representative of the networking system comprises:

producing a virtualization of the networking system to produce the simulated environment.

14. The method of claim 11 wherein modeling the change within the simulated environment through the manipulation of the parameter within the simulated environment includes:

varying a number of virtual devices supported by the device to model the change within the simulated environment.

15. The method of claim 11 comprising:

manipulating a different parameter within the simulated environment to model a different change; and

determining the responsiveness of the device based on the different modeled change.