TOPOLOGY-BASED VIRTUAL SWITCHING MODEL WITH PLUGGABLE FLOW MANAGEMENT PROTOCOLS

The disclosure relates to technology for supporting multiple flow management protocols in a virtual network switch and changing a flow management protocol without changing switch topology configurations at run time. A data plane provider is detected via a pluggable software module (or plugin or plugin module) that identifies and controls the data plane provider with network interfaces and enables flow management protocols. A switch topology is then constructed by creating a virtual switch object, adding ports to the virtual switch object. A datapath is then created using the switch topology and the first flow management protocol on the data plane provider. Network interfaces are connect to each ports respectively to enable communication among the entities attached to each network interface according to the first flow management protocol. The datapath can be later changed to use the second flow management protocol and retain the same topology at run time.

BACKGROUND

A network switch is a hardware device for making data connections among devices. Switches may be employed to receive, process and forward data packets to their intended destination according to specific flow management protocols (or called data forwarding protocols). Moreover, network switches can have two planes: a control plane and a data plane. The control plane is a portion of the system responsible for providing the flow management protocol functions and features of the system. The data plane is responsible for actually receiving, processing and sending data from and to the ports that connect the switch to external sources according to the logic provided by the control plane.

Network switches may be deployed as physical hardware or may be virtually deployed using software that provides network connectivity for systems employing virtualization technologies. Virtualization technologies allow one computer to do the job of multiple computers by sharing resources of a single computer across multiple systems. Through the use of such technology, multiple operating systems and applications can run on the same computer at the same time, thereby increasing utilization and flexibility of hardware. Virtualization allows servers to be decoupled from underlying hardware, thus resulting in multiple VMs sharing the same physical server hardware.

When any of the multiple virtual computer systems communicate one with another, they can communicate within the single physical computing device via the virtual switch. In other words, network traffic with a source and destination within the single physical computing device do not exit the physical computer system.

With network virtualization technology being widely adopted, virtual switch functionalities, protocols, hardware accelerators, etc. are emerging quickly. Under many circumstances, different virtual switch implementations with different protocols from different vendors may be used in a single system, which makes switch configuration tasks complicated or even impossible.

BRIEF SUMMARY

In one embodiment, there is a method for supporting multiple flow management protocols in a virtual network switch (vSwitch), comprising detecting a data plane provider, the data plane provider discoverable via a pluggable software module that identifies a data plane of the data plane provider with one or more network interfaces and enables one or more flow management protocols; and configuring a virtual switch to use a first flow management protocol of the one or more flow management protocols enabled by the pluggable software module by constructing a topology of the virtual switch by creating a virtual switch object on a virtual switch framework, and adding one or more ports to the virtual switch to form the topology; creating a first datapath on the data plane provider using the topology with the first flow management protocol; and connecting a first network interfaces of the one or more network interfaces to a first port of the one or more ports and a second network interface of the one or more network interfaces to a second port of the one or more ports to enable communication among one or more entities attached to each of the network interfaces by forwarding data packets within the first datapath using the first flow management protocol.

In another embodiment, there is a non-transitory computer-readable medium storing computer instructions for supporting multiple protocols in a network, that when executed by one or more processors, perform the steps of detecting a data plane provider, the data plane provider discoverable via a pluggable software module that identifies a data plane of the data plane provider with one or more network interfaces and enables one or more flow management protocols; and configuring a virtual switch to use a first flow management protocol of the one or more flow management protocols enabled by the pluggable software module by constructing a topology of the virtual switch by creating a virtual switch object on a virtual switch framework, and adding one or more ports to the virtual switch to form the topology; creating a first datapath on the data plane provider using the topology with the first flow management protocol; and connecting a first network interfaces of the one or more network interfaces to a first port of the one or more ports and a second network interface of the one or more network interfaces to a second port of the one or more ports to enable communication among one or more entities attached to each of the network interfaces by forwarding data packets within the first datapath using the first flow management protocol.

In still another embodiment, there is a node for supporting multiple protocols in a network, comprising a memory storage comprising instructions; and one or more processors coupled to the memory that execute the instructions to: detect a data plane provider, the data plane provider discoverable via a pluggable software module that identifies a data plane of the data plane provider with one or more network interfaces and enables one or more flow management protocols; and configure a virtual switch to use a first flow management protocol of the one or more flow management protocols enabled by the pluggable software module by constructing a topology of the virtual switch by creating a virtual switch object on a virtual switch framework, and adding one or more ports to the virtual switch to form the topology; creating a first datapath on the data plane provider using the topology with the first flow management protocol; and connecting a first network interfaces of the one or more network interfaces to a first port of the one or more ports and a second network interface of the one or more network interfaces to a second port of the one or more ports to enable communication among one or more entities attached to each of the network interfaces by forwarding data packets within the first datapath using the first flow management protocol.

DETAILED DESCRIPTION

The disclosure relates to technology for a virtual switch framework that uses a unified topology management interface and supports multiple data plane providers with different flow management protocols enabled by dynamically pluggable modules.

Multiple flow management protocols are supported in a virtual network switch and a flow management protocol may be changed to another protocol without changing switch topology configurations at run time. A data plane provider is detected via a pluggable software module (or plugin or plugin module) that identifies and controls the data plane provider with network interfaces and flow management protocols. A switch topology is then constructed by creating a virtual switch object, adding ports to the virtual switch object. A datapath is then created using the switch topology and the first flow management protocol on the data plane provider. Network interfaces are connect to each ports respectively to enable communication among the entities attached to each network interface according to the first flow management protocol. The datapath can be later changed to use the second flow management protocol and retain the same topology at run time.

It is understood that the present invention may be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete and will fully convey the invention to those skilled in the art. Indeed, the invention is intended to cover alternatives, modifications and equivalents of these embodiments, which are included within the scope and spirit of the invention as defined by the appended claims. Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be clear to those of ordinary skill in the art that the present invention may be practiced without such specific details.

FIG. 1illustrates a processing environment for a group of computing devices connected to a management station via a network switch. As illustrated, the processing environment100includes, but is not limited to, network102, management station104, switches106A,106B and computing devices108A,108B,108C. It is appreciated that the illustrated embodiment is intended as an example, and that any number of computing devices, switches, networks and management stations may be employed.

The network102may be any public or private network, or a combination of public and private networks such as the Internet, and/or a public switched telephone network (PSTN), or any other type of network that provides the ability for communication between computing resources, components, users, etc., and is coupled in the example embodiment to a respective one of switches106A,106B. Each of the switches106A,106B (which may be physical or virtual) includes a respective forwarding data structure (e.g., a forwarding information base (FIB) or forwarding table, not shown) by which switches106A,106B forward incoming data packets toward a destination based upon, for example, OSI Layer 2 addresses (e.g., based on MAC addresses) contained in the packets.

The computing devices108A,108B,108C, such as a host, are coupled to a respective one of the switches106A,106B. Each of the computing devices108A,108B,108C respectively includes, for example, a virtual machine (VM)116A/118A,116B/118B,116C/118C and a virtual machine monitor (VMM) or hypervisor110A,110B,110C and a network interface card (NIC)124A,124B,1224C. Each of the VMMs110A,110B,110C include, for example, a virtual switch or vSwitch (VS)112A,112B,112C and a port selector114A,114B and114C. The VMs116A/B,116B/118B,116C/118C each include a corresponding NIC120A/122A,120B/122B,120C/122C, such as a virtual NIC (vNIC). It is appreciated that the components, such as the NIC, vNIC, Switch, vSwitch, etc., may be exchanged or replaced with either physical or virtual components, or any combination of hardware and/or software.

Each computing device108A,108B and108C executes a respective one of VMMs110A,110B,110C, which virtualizes and manages resources on the respective computing device108A,108B and108C. The computing devices108A,108B and108C may be any type of device, such as a server or router, which may implement the procedures and processes described herein as detailed inFIGS. 3-8below. Moreover, the computing devices108A,108B and108C for example, may execute the VMMs110A,110B,110C under the direction of a human and/or automated cloud administrator at a management station104coupled to the computing devices108A,108B and108C by network102.

VMMs110A,110B,110C on computing devices108A,108B,108C support the execution and operation of VMs116A/118A,116B/118B,118C/118C, and implement VSs112A,112B,112C and port selectors114A,114B,114C in support of respective VMs. The port selectors114A,114B,114C determine the type of the ports of the VSs112A,112B,112C and ensure proper connection of the NICs124A,124B,124C to the network102. It should also be appreciated the while two VMs are illustrated as being deployed on each of the computing devices, any number of VMs and interfaces may be employed in the computing devices. Each of the VMs116A,116B,116C may be associated with various entities, such as data providers or consumers (explained further below).

VMs116A/118A,116B/118B,116C/118C each include a respective vNIC120A/122B,120B/122b,120C/122C. A vNIC120A/122B,120B/122B,120C/122C facilitates communication via a port of a particular VS. Communications between VMs116A,118A,116B,118B,116C,118C may be routed via software of VSs112A,112B,112C and physical switches106A,106B.

FIG. 2illustrates a virtual switching management system having pluggable flow management protocols. The virtual switching management system200includes, for example, a configurator202, a virtual switch framework204, a data plane provider206and a protocol controller208. A data plane provider may be any hardware or software module which can receive, process and send data packets with the logic (flow management protocols) prescribed by its controller. With this system, multiple protocols from various data plane providers may be supported. Thus, the system is not limited to a layer 2 or layer 3 switch or similar, but may also include other types of flow management protocols such as openflow or a fully customizable switching policy. Whereas traditional virtual switch implementations are designed to support data plane provider specific flow management protocols, the management system200provides a framework to support multiple data plane providers with different flow management protocols enabled by pluggable software modules (i.e., plugin or plugin module), and the flow management protocol of a running virtual switch can be changed without changing the already configured switching topologies. Flow management protocols can therefore be changed or modified at runtime, and multiple switch instances can support different protocols at the same time.

The configurator202includes a command line interface (CLI) and/or application programming interface (API)202A that enables a user of the system to configure and manage the virtual switch objects and their respective topologies. The configurator202is also responsible for maintaining the configuration records. Such records may be stored in configuration store202B. The configuration store202B may be, for example, a database, memory, storage system or any other component or element capable of storing information. Moreover, the configuration storage202B may reside outside of the configurator202as independent storage or on any other system component that is in communication with the management system200.

VS framework204includes virtual switch topology configuration and switch object management functionality. As noted above, the VS on the framework204may be configured (or re-configured) by the configurator202. The VS framework204includes, but is not limited to, a topology manager204A, a provider manager204B, a features manager204C, a plugin manager204D and an event manager204E. The topology manager204A is responsible for configuring and managing data plane objects and their topologies (namely the virtual switches and their ports and connected interfaces).

The provider manager204B is responsible for discovering and managing specific instances of the data plane providers206using, in some embodiments, various software and/or hardware co-processors and accelerators. Thus, the provider manager204B may identify data plane providers206via the plugin modules which enable and manage their respective providers and protocols. The provider manager204B may also monitor for newly added plugins to assist in discovering and managing instances of the new protocols and data plane providers206. Once discovered, the data plane providers206and their respective plugins may be configured to interface with and operate on the virtual switching management system200, or to otherwise enable or make available any new functionality.

The features manager204C manages common features of the data plane objects, such as monitoring protocols, quality of service, etc. However, the features manager204C is not typically responsible for features related to the flow management protocols. In general, the features manager204C will be responsible for making decisions about whether a data plane provider206implements certain features and requests execution of those features when appropriate. In one embodiment, the features manager204C may be responsible for managing the creation and removal of switching and port features.

The plugin manager204D manages the pluggable software modules (plugins) to enable the data plane provider's206flow management protocols. The plugin manager204D is responsible for integrating functionality from the plugins.

The plugin manager204D may also be responsible for loading plugins. In another embodiment, the plugin manager204D may apply loading criteria such that specific plugins meeting the loading criteria are loaded. For example, loading criteria may include a timestamp (e.g., load plugins created after a specific date), version number (e.g., load the latest version number of a plugin if multiple versions are present), or specific names of data plane providers206.

The plugin manager204D may also assist in determining which plugins to load and gather information necessary to load selected plugins. The plugin manager204D may also receive configuration data from the configuration store202B of configurator202.

Plugins may have a common interface that enables it to be loaded by plugin manager. Each plugin is to perform specific functions (e.g., enable flow management protocols) or to perform specific configuration tasks and/or provide specific information to communicate with various components in the system. When a plugin is loaded, any plugin-specific initialization may also be performed. Examples of plugin-specific initialization include creating and/or verifying communication connections, loading classes, directing plugin manager204D to load or unload additional plugins, etc.

The event manager204E is responsible for handling events at runtime and scheduling tasks for the virtual switch framework204.

Data plane provider206is responsible for providing provider-specific flow management protocols and implementing APIs to interactive with the virtual switch framework204. The data plane provider206includes a protocol manager206A and data plane206B. The data plane providers206may be represented by the pluggable software modules (plugins) that may be implemented as specific flow management protocols and which implement APIs to interact with the VS framework204. These plugins may enable the data plane206B to forward packets of information based on the flow management protocols defined by the plugin.

As appreciated, the data plane206B may receive packets, process and forward packets in a manner using the flow management protocols provided by the data plane provider. Specifically, the data plane is responsible for the ability of a computing device, such as a router or server, to process and forward packets, which may include functions such as packet forwarding (packet switching), which is the act of receiving packets on the computing device's interface. The data plane206B may also be responsible for classification, traffic shaping and metering.

The plugins enable the respective data plane providers206to implement data forwarding functionalities according to predefined or customized flow management protocols. In one embodiment, each plugin may be a stand-alone software library module that is independent from the VS framework204. Such independent plugins may be added and/or removed. In another embodiment, one or more plugins may rely on the VS framework204to provide additional functionality.

FIG. 3illustrates a unified modeling language (UML) static class diagram of a data model for the virtual switch framework ofFIG. 2. The model allows the VS framework204to be implemented to support multiple virtual switches on different data plane providers with different flow management protocols enabled by respective plugin modules, and to support changing flow management protocols without changing switch topology configurations.

A class describes a set of objects that share the same specifications of features, constraints, and semantics. For example, the object for a plugin contains the class “plugin,” with attributes “name, type” and method of execution as “provider_discovery,” “add_provider” and “delete_provider.” In addition, relationships may exist between objects such that connections are found in a class and object diagram. Relationships depicted in the diagram ofFIG. 3are as follows. An association (ASSOC) specifies a semantic relationship that can occur between typed instances. Aggregation (AGG) is more specific than an association, such as an association that represents a part-whole or part-of relationship. An association (ASSOC) may represent a composite aggregation (i.e., a whole/part relationship). Composite aggregation (CAGG) is a strong form of aggregation that requires a part instance be included in at most one composite at a time, and a composition is represented by the attribute on the part end of the association being set to true. The graphical representation of a composition relationship is a filled diamond shape on the containing class end of the tree of lines that connect contained class(es) to the containing class. A generalization (GEN) is a taxonomic relationship between a more general classifier and a more specific classifier. The graphical representation of a generalization is a hollow triangle shape on the superclass end of the line that connects it to one or more subtypes.

FIG. 4illustrates a sequence diagram for loading plugins, discovering providers and the flow management protocols they support. Implementing the process ofFIG. 4allows the virtual switching management system200to dynamically add, change or modify protocols from at least a first protocol to at least one other protocol. In the discussion that follows, VS framework204performs the process detailed in the sequence diagram in association with the data plane206B of data plane provider206(e.g., provider A and provider B). However, it is appreciated that such operation is not limited to the aforementioned components. Moreover, the process disclosed inFIG. 4is one example of discovering providers with different flow management protocols. It is therefore appreciated that the process disclosed is a non-limiting example.

In the example depicted inFIG. 4, after the plugin manager of VS framework204finds and then calls add_plugin (“plugin module for provider A”) to load the plugin which enables the provider A206A with specific flow management protocols, such as protocol1and protocol2. The VS framework204then calls the “provider_discovery( )” of the newly added (or modified) plugin to obtain the property information of the provider. The data plane provider A206that is enabled by the plugin returns the name of the provider, along with the associated network interface(s) and flow management protocol(s) it supports. For example, data plane provider206(provider A) has two network interfaces (“if1” and “if2”) and supports two flow management protocols (“protocol1” and “protocol2”), and returns {“provider A”, “if1, if2”, “protocol1and protocol2”}. Upon the data plane provider A206returning the information to the VS framework204, the VS framework204registers the provider A with the property information, including the supported protocols and associated network interfaces for later use by calling methods such as “provider_add( ),” and “providerA.add_interface( ).”

A similar process occurs for the discovery of another data plane provider206, such as provider B. In this example, provider B has two network interfaces (“if3” and “if4”) and a single flow management protocol (“protocol1”), which information is stored for example in a plugin module of data plane provider206.

FIG. 5illustrates a sequence diagram for creating a switch associated with the discovered data plane providers ofFIG. 4. In the example embodiment, a switch is created such that a protocol being used for communication between entities may be changed, for example during runtime, to a newly discovered protocol without affecting the switch topology configuration. In the explanation that follows, the configurator202, VS framework204and data plane provider206are responsible for implementing the process. However, it is appreciated that implementation is not limited to these components.

The process of creating the switch is initiated by configurator202first constructing a switch topology. For example, a switch topology “topology0” can be constructed by the following process: the configurator202calls “create_switch(“sw0”) to instruct the VS framework204to create the switch object (“sw0”), and then calls “sw0.create_port(“p01”)” to create a first port (“p01”) associated with the switch. Similarly, a second port (“p02”) is created associated with the switch object (“sw0”). It is appreciated that the two ports are an example, and that any number of ports may be associated with the switch. In one embodiment, the number of ports created correspond to the number of network interfaces on the data plane provider206to be used.

Once the switch object (“sw0”) and associated topology “topology0” have been created, the configurator202may call “providerA.add_switch(sw0, “protocol1”)” to instruct the VS framework204to create the switch on the data plane provider206(provider A) using the first protocol (protocol1).

The VS framework204then sends a request to the data plane provider206(“providerA.add_datapath(“protocol1”, “topology0”) to create a datapath (dp1). The creation of the datapath (dp1) from the data plane provider206(provider A) to the VS framework204means the switch (“sw0”) is now ready for forwarding data between the ports according to “protocol1” along the datapath dp1(after interfaces are connected to ports). The configurator202can instruct the VS framework204to connect the first port (“p01”) to the first network interface (“if1”) by calling “p01.connect_interface(if1).” Similarly, the configurator202can instruct the VS framework204to connect the second port (“p02”) to the second network interface (“if2”) by calling “p02.connect_interface(if2).”

The virtual switch (VS)206C may now be used to send data packets using the flow management protocol (in this case, protocol1) of the data plane provider206(in this case, provider A). Thus, entities may now communicate with one another via the first (“if1”) and second (“if2”) network interfaces connected to the ports of virtual switch (VS)206C with the designated flow management protocol “protocol1.” For example, a VM116A may send a data packet via the virtual switch (VS)206C to another VM118A using protocol1along the datapath dp1via vNIC120A and vNIC122A. As data packets arrive at the virtual switch (VS)206C created on behalf of the data plane provider206(provider A), they may be parsed (e.g., determine a destination address of the packet) and matched to specific actions and forwarded using the flow management protocol (e.g., protocol1) by the data plane206B.

It is appreciated that while two VMs are communicating in the disclosed embodiment, any number of VMs may be communicating through any number of network interfaces and ports, and the disclosed embodiment is a non-limiting example.

When a user wants to change flow management protocols, the virtual switch management system200may change flow management protocols without changing the topology of the virtual switch (VS)206C. In particular, the configurator202requests a change in flow management protocol from protocol to protocol2, such as “sw0.change_protocorprotocol2”), to the VS framework204. The VS framework204, in response to the request from the configurator202, forwards the request to remove the first datapath (dp1) to the data plane provider206(provider A), such as in the form of the following instruction “dp1.delete_datapath( ).”

In response to the instruction, the datapath (dp1) is removed and the VS framework204requests that a new datapath (also, dp1) be created using the second flow management protocol (protocol2) without changing the topology (topology0). Once the datapath (dp1) is created, the switch (“sw0”) is ready to communicate using the second flow management protocol (protocol2). Notably, there is no need to create or re-create the virtual switch (“sw0”) in order to change flow management protocols. That is, the switch remains connected using the previously created topology and may now be used to send data packets using the new flow management protocol (in this case, protocol2) of the data plane provider206(in this case, provider A). Thus, entities (such as VMs) may now communicate with one another using the virtual switch (VS)206C with the newly designated flow management protocol (in this case, protocol2).

FIG. 6illustrates one embodiment of a flow diagram for configuring a virtual switch with multiple protocols using a pluggable software module in accordance withFIGS. 1-5. At602, the VS framework204monitors the virtual switching management system200to detect data plane providers by discovering newly created or modified plugins. The VS framework204continues to monitor for plugins until detection (discovery) of a plugin of a data plane provider206. At604, the VS framework204determines whether a plugin of a data plane provider206has been detected. If no plugin is detected at604, the process continues to monitor for detected plugins at602. Otherwise, when the VS framework204detects a new plugin, the newly added functionalities including flow management protocols enabled by the plugin can be used for configuring a new virtual switch or modifying an existing virtual switch (VS)206C at606.

As part of configuring the virtual switch (VS)206C at606, a topology (e.g., topology0) is constructed at608by creating a virtual switch object on the VS framework204, and adding one or more ports to the virtual switch (VS)206C. After the topology is constructed, a datapath (e.g. dp1) is created on the data plane provider206using the topology (topology0) and the flow management protocol at610. Then, at612, the virtual switch (VS)206C is ready to perform according to the flow management protocol as set forth in the plugin by connecting the network interface(s) to corresponding port(s) to enable communication of entities attached to the network interface(s) by implementing the flow management protocol along the datapath. Accordingly, a first entity (e.g., VM116A) may communicate via vNIC120A with a second entity (e.g. VM118A) via vNIC122A using a specified flow management protocol.

FIG. 7illustrates another flow diagram for configuring a virtual switch with multiple protocols using a pluggable software module (plugin) in accordance withFIGS. 1-5. Recall in the process ofFIG. 4that provider A has two protocols, namely protocol1and protocol2. At702, the VS framework204reconfigures the virtual switch to use the second flow management protocol (protocol2) to enable communication among the entities attached to each for the network interfaces by forwarding data packets within a second datapath (dp1) using the second flow management protocol.

In reconfiguring the virtual switch, the VS framework204receives a request from the configurator202to modify (e.g., change or update) the first flow management protocol (“protocol1”) to a second flow management protocol (“protocol2”) at704. The data plane206B, similar to above, is identified by the VS framework204as a modified plugin with a changed or updated flow management protocol. To change or update flow management protocols requested at704, the VS framework204forwards the request from the configurator202to remove the first datapath (dp1) to the data plane provider206at706. The first datapth (dp1) is then removed.

Subsequently, the VS framework204requests that a new (second) datapath (dp1) be created to enable the second flow management protocol (protocol2), while maintaining the topology of the virtual switch (VS)206C. This is accomplished by configuring the virtual switch (VS)206C to implement the second flow management protocol (“protocol2”) which could be enabled by an updated or modified plugin to establish the communication. That is, the virtual switch (VS)206C is configured to implement the second flow management protocol (“protocol2”) by replacing the first flow management protocol (“protocol1”) at708. Entities attached to the first (“if1”) and second (“if2”) network interfaces are now able to communicate using the second flow management protocol (“protocol2”).

FIG. 8is a block diagram of a network system that can be used to implement various embodiments. Specific devices may utilize all of the components shown, or only a subset of the components, and levels of integration may vary from device to device. Furthermore, a device may contain multiple instances of a component, such as multiple processing units, processors, memories, transmitters, receivers, etc. The network system may comprise a processing unit801equipped with one or more input/output devices, such as network interfaces, storage interfaces, and the like. The processing unit801may include a central processing unit (CPU)810, a memory820, a mass storage device830, and an I/O interface860connected to a bus870. The bus870may be one or more of any type of several bus architectures including a memory bus or memory controller, a peripheral bus or the like. The CPU810may comprise any type of electronic data processor, which may be configured to read and process instructions stored in the memory820.

The memory820may comprise any type of system memory such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), a combination thereof, or the like. In an embodiment, the memory820may include ROM for use at boot-up, and DRAM for program and data storage for use while executing programs. In embodiments, the memory820is non-transitory.

The mass storage device830may comprise any type of storage device configured to store data, programs, and other information and to make the data, programs, and other information accessible via the bus. The mass storage device830may comprise, for example, one or more of a solid state drive, hard disk drive, a magnetic disk drive, an optical disk drive, or the like.

The mass storage device830may also include a virtualization module830A and application(s)830B. Virtualization module830A may represent, for example, a hypervisor of a computing device108A, and applications830B may represent different VMs. The virtualization module830A may include a switch (not shown) to switch packets on one or more virtual networks and be operable to determine physical network paths. Applications830B may each include program instructions and/or data that are executable by computing device108A. As one example, application(s)830B may include instructions that cause computing device108A to perform one or more of the operations and actions described in the present disclosure.

The processing unit801also includes one or more network interfaces850, which may comprise wired links, such as an Ethernet cable or the like, and/or wireless links to access nodes or one or more networks880. The network interface850allows the processing unit801to communicate with remote units via the networks880. For example, the network interface850may provide wireless communication via one or more transmitters/transmit antennas and one or more receivers/receive antennas. In an embodiment, the processing unit801is coupled to a local-area network or a wide-area network for data processing and communications with remote devices, such as other processing units, the Internet, remote storage facilities, or the like.

As a result of the virtual switch framework with pluggable flow management modules discussed above, several advantages are provided including, but not limited to, changing or updating underlying switching protocols without interrupting the network operations based on the running switch topology, new switching protocols or providers can be added at runtime without affecting currently active switching providers and protocols on the system, use existing common topology management functionalities provided by the framework, a unified system to manage multiple different types of virtual switches, eliminating operation down time for service providers and users given the ability to change or update underlying switching protocols without interrupting virtual networking operations, reducing time and cost of developing new protocol providers given the common topology management functionalities provided by the framework implementation of new switch protocol providers, reducing the complicity of switch management and operator's learning curve given the unified interfaces that can be used for managing multiple different types of virtual switches, and reducing human errors when changing switch protocols since the switch object and its topology configuration can be retained without reconfiguration.

In accordance with various embodiments of the present disclosure, the methods described herein may be implemented using a hardware computer system that executes software programs. Further, in a non-limited embodiment, implementations can include distributed processing, component/object distributed processing, and parallel processing. Virtual computer system processing can be constructed to implement one or more of the methods or functionalities as described herein, and a processor described herein may be used to support a virtual processing environment.

For purposes of this document, each process associated with the disclosed technology may be performed continuously and by one or more computing devices. Each step in a process may be performed by the same or different computing devices as those used in other steps, and each step need not necessarily be performed by a single computing device.