Network compatibility determination based on flow requirements of an application and stored flow capabilities of a software-defined network
In one example, a software-defined networking (SDN) controller can access flow capability information for flow paths along network data path elements in the control plane of the SDN controller. The SDN controller can determine network compatibility for an SDN controller application based on whether the accessed flow capability information fails to meet a flow requirement for the application. The SDN controller can further notify the application when it is determined that the flow requirements for the application are not met by a flow path. Related methods and machine-readable storage mediums are also described.
Latest Hewlett Packard Patents:
In a software-defined network (SDN), control decisions for routing traffic through the network can be decoupled from the network's physical infrastructure. For example, in some SDNs, a network controller can instruct network switches to flow traffic along a selected routing path defined by network switches. Other functionality can be achieved through the use of software-defined networking. For example, SDN applications can be installed on or interface with a network controller to meet customer use cases, such as to achieve a desired throughput or other quality of service.
In an SDN, each SDN-compatible network data path element (such as an SDN-compatible network switch) can have a diverse set of capabilities. Applications for managing SDNs can be designed to require a certain set of capabilities for operation or may make control decisions for the SDN based on the capabilities of each network data path element. Although certain switch capabilities can typically be found in documentation from the vendor, this information can be cumbersome to access and can change based on firmware or other software upgrades. Due to the increasing complexity of modern SDN arrangements, it can be challenging for a network administrator to determine whether a specific SDN application could actually be successfully deployed on an SDN network and whether adding or removing a data path element would affect the compatibility of the SDN application. As a result, network administrators will often test compatibility through a trial-and-error approach and may be hesitant to make large changes to SDNs so as to minimize troubleshooting difficulties.
Certain implementations of this disclosure address these issues by providing an SDN controller service that maps SDN application requirements with capabilities advertised by SDN-compatible network data path elements along a data flow path. Certain implementations can, for example, use the advertised capabilities to determine in real time if the underlying network can support a SDN application given its flow requirements. An SDN application developer can, for example, rely on such an SDN controller service to design for cases when the underlying network can no longer support the application's flow requirement, such as by instructing an SDN controller to take an alternative flow signature or work with a lower scale.
In the example SDN 100 depicted in
The functionality of SDN controller 102 can, for example, be implemented in part using a software program on a standalone machine, such as a server. In some implementations, SDN controller 102 can be implemented on multi-purpose machines, such as a suitable desktop computer, laptop, tablet, or the like. In some implementations, SDN controller 102 can be implemented on a suitable non-host network node, such as certain types of network switches. It is appreciated that the functionality of SDN controller 102 may be split among multiple controllers or other devices. For example, SDN 100 is described and illustrated as including only one SDN controller 102. However, it is appreciated that the improved systems, methods, and mediums described herein can be implemented in SDNs with multiple controllers. For example, in some SDNs, network devices are in communication with multiple controllers such that control of the network can be smoothly handed over from a first controller to a second controller if a first controller fails or is otherwise out of operation. As another example, multiple controllers can work together to concurrently control an SDN. In such SDNs, a first controller can, for example, control certain network devices while a second controller can control other network devices. In view of the above, reference in this application to a single SDN controller 102 that controls the operation of SDN 100 is intended to include such multiple controller configurations (and other suitable multiple controller configurations).
This information can, for example, be determined from information received via a suitable SDN protocol command, such as the OFPMP_TABLE_FEATURES command for OpenFlow compatible switches. Using this command, SDN controller 102 can instruct a controlled switch to communicate the specific details of the OpenFlow pipeline it supports and provides a mechanism for the switch to advertise the flow tables that it supports as part of its OpenFlow pipeline as well as the capabilities & capacities of each of those flow tables. For example, the OFPMP_TABLE_FEATURES command can instruct the switch to communicate details regarding an OpenFlow table in its pipeline: (a) table ID, (b) max number of entries, (c) metadata match and write, (d) match fields supported, (e) instruction types supported, and (f) packet modifications supported.
In some implementations, the SDN controller service accesses the flow capability database, but does not itself create the database. For example, the database can be created by a vendor or network administrator. In some implementations, however, method 124 can include a separate step of SDN controller 102 creating the flow capability database or amending the flow capability database.
In some implementations, a step of creating the flow capability database can include a third sub-step of determining flow capability information for each queried network data path element based on the received table capability information for each queried network data path element and a fourth sub-step of storing in the flow capability database the determined flow capability information for each queried network data path element. Flow capability information can, for example, be determined for a given flow path based on the capability information for each network data path element within the flow path. For illustration, a potential flow path can include two switches, with a first switch configured to allow a first maximum number of entries and a second switch configured to allow a second maximum number of entries. This information can be entered in the flow capability database for the potential flow path. For some flow path capabilities, the capabilities of all network data path elements in the flow path are used to determine the overall capabilities of a flow path. For example, an overall maximum number of entries for a given flow path can be determined to be the lesser of the first and second maximum number of entries for the two switches in the example flow path above. For some flow path capabilities, the presence of a single network data path element including a capability, such as an ability to modify packets, may be sufficient to determine a capability for the entire flow path.
Method 124 includes a step 128 of SDN controller 102 determining, based on the accessed flow capability database, whether flow capability requirements for an application to be run on SDN controller 102 are met by a flow path along network data path elements. Applications to be run on SDN controller 102 can include Quality of Service (QoS) applications, security applications, network forwarding applications, energy efficiency applications, or other types of applications.
Step 128 can, for example, be accomplished by comparing a flow capability requirement value to a flow capability value for a given flow path. For example, if an SDN application requires that a given flow path be able to support 10,000 table entries, step 128 can include determining, based on the flow capability information for a given flow path in the database, whether the flow path can support more than 10,000 table entries. It is appreciated that step 128 can include any suitable determination calculation, such as determinations based on multiple flow capabilities. For example, an SDN application may require that a given flow path be able to support 10,000 table entries if the flow path is unable to modify packets, but may require that a flow path be able to support only 5,000 table entries if the flow path is able to modify packets. It is appreciated that this determination can be based on any single flow requirement or combination of flow requirements that may be relevant in the SDN field.
Method 124 includes a step 130 of SDN controller 102 notifying the SDN application when it is determined that the flow capability requirements for the SDN application are not met by a flow path. It is appreciated, that in some implementations, step 130 of SDN controller 102 can include notifying the SDN application when it is determined that the flow capability requirements for the SDN application are not met by any flow paths within the SDN. That is, the failure of a given flow path (of many) may not warrant a notification to the SDN application if other flow paths are compatible with the application. A given flow path can, for example, be selected by a network administrator for evaluation. In some implementations, a set of flow paths are selected when a new network datapath element is added to the network. For example, any flow path created by the addition of a network datapath element can be selected for evaluation. In some implementations, every flow path is reevaluated when a new network datapath element is added to the network.
In some implementations, step 130 can include identifying a flow capability requirement that was determined as not being met by a flow path (or in some cases a network data path element in a given flow path). In some implementations, step 130 can include providing the application with a list of flow tables on each data path that support the flow capability requirements. It is appreciated that other notifications can provide additional or alternative information, such as identification of a network data path element that fails to meet a flow requirement. The form of the notification provided in step 130 (e.g., a message to the SDN application, an audio or visual indicator, etc.) can be based on the hardware of a notification module (see, e.g., notification module of
In some implementations, step 130 can include determining whether every switch requirement for an application to be run on the SDN controller is met by every corresponding switch capability for each network switch in the control domain of the SDN controller. Moreover, step 130 can include determining whether every switch requirement for every application to be run on the SDN controller is met by every corresponding switch capability for each network switch in the control domain of the SDN controller. In such implementations, notification step 130 can include sending an error message to any application when any switch capability fails to meet any switch requirement.
Method 124 can include a separate step of updating a flow capability database when SDN 100 is updated, such as when a network data path element is updated, added to SDN 100, and/or removed from SDN 100. Updating the flow capability database can include receiving, with SDN controller 102, an indication that a network data path element has been added to a control plane of SDN controller 102. Updating the flow capability database can include querying an added network data path element regarding its table capabilities. This querying step can be similar to the steps described above regarding determining table capabilities for a network data path element. For example, SDN controller 102 can send a network data path element an OFPMP_TABLE_FEATURES command that instructs the network data path element to communicate details regarding an OpenFlow table in its pipeline. Updating the flow capability database can include a sub-step of receiving table capability information for added network data path element. Updating the flow capability database can include a sub-step of determining flow capability information for added network data path element based on the received table capability information for added network data path element. Updating the flow capability database can include a sub-step of storing in the flow capability database the determined flow capability information for added data path element.
Method 124 can include a separate step of updating a flow capability database when a network data path element is removed from the network. Updating the flow capability database for a removed network data path element can include receiving, with SDN controller 102, an indication that a network data path element has been removed from a control plane of SDN controller 102. Updating the flow capability database under this condition can include updating the flow capability database to remove the flow capability information for the removed network data path element.
Although the flowchart of
Computing system 132 can be in the form of a suitable server, desktop computer, laptop, tablet, or the like. In some implementations, software that provides the functionality of SDN controller 102 can be stored on machine-readable storage medium 136 of computing system 132 to be executed by processor 134 of computing system 132. In some implementations, computing system 132 can be a standalone personal computer that is connected to SDN controller 102 so as to communicate with SDN controller 102 to execute one or more steps of method 124. In such implementations, computing system 132 can receive information from SDN controller 102 through direct or indirect means. For example, computing system 132 may communicate with SDN controller 102 by a wired data cable or wireless connection. In some implementations, computing system 132 communicates with SDN controller 102 through the use of a removable data storage device, such as a USB thumb drive or a storage disc.
Processor 134 of computing system 132 can, for example, be in the form of a central processing unit (CPU), a semiconductor-based microprocessor, a digital signal processor (DSP) such as a digital image processing unit, other hardware devices or processing elements suitable to retrieve and execute instructions stored in medium 136, or suitable combinations thereof. Processor 134 can, for example, include single or multiple cores on a chip, multiple cores across multiple chips, multiple cores across multiple devices, or suitable combinations thereof. Processor 134 can be functional to fetch, decode, and execute instructions as described herein. As an alternative or in addition to retrieving and executing instructions, processor 134 can, for example, include at least one integrated circuit (IC), other control logic, other electronic circuits, or suitable combination thereof that include a number of electronic components for performing the functionality of instructions stored on medium 136. Processor 134 can, for example, be implemented across multiple processing units and instructions may be implemented by different processing units in different areas of computing system 132.
SDN controller service instructions 104 can be executable by processor 134 such that computing system 132 is operative to perform one or more SDN controller services described herein, such as those described above with respect to method 124. Related data stored on medium 136 can, for example, include flow capabilities for one or more network data path elements and flow requirements for one or more SDN applications. It is appreciated that instructions and data can be stored on separate machine-readable storage mediums. For example, SDN controller service instructions 104 can be stored on a first machine-readable storage medium 136, flow capabilities can be stored in a database on a second machine-readable storage medium 136, and flow requirements for SDN applications can be stored on a third machine-readable storage medium 136. Multiple mediums can be treated as a single medium 136 for purposes of description.
Medium 136 of computing system 132 can, for example, be in the form of a non-transitory machine-readable storage medium, such as a suitable electronic, magnetic, optical, or other physical storage apparatus to contain or store information such as executable SDN controller service instructions 104, related data, and the like. Medium 136 can, for example, be housed within the same housing as processor 134 for computing system 132, such as within a computing tower case for computing system 132. In some implementations, medium 136 and processor 134 are housed in different housings. As used herein, the term “machine-readable storage medium” can, for example, include Random Access Memory (RAM), flash memory, a storage drive (e.g., a hard disk), any type of storage disc (e.g., a Compact Disc Read Only Memory (CD-ROM), any other type of compact disc, a DVD, etc.), and the like, or a combination thereof. In some implementations, medium 136 can correspond to a memory including a main memory, such as a Random Access Memory (RAM), where software may reside during runtime, and a secondary memory. The secondary memory can, for example, include a nonvolatile memory where a copy of software is stored.
SDN controller 102 of
Comparison module 140 is a functional module of SDN controller 102 that includes a combination of hardware and software that allows SDN controller 102 to determine whether one or more flow capabilities 144 retrieved from storage module 138 for a specific network data path element fails to meet one or more flow requirements 146 retrieved from storage module 138. In some implementations, comparison module 140 includes hardware in the form of a microprocessor on a single integrated circuit, related firmware, and other software for allowing the microprocessor to operatively communicate with other hardware of SDN controller 102. Comparison module 140 can include software instructions and/or algorithms used by SDN controller 102 to compare flow capabilities 144 to flow requirements 146. Comparison module 140 can, for example, include one or more machine-readable storage mediums, such as medium 136 described above with respect to
Notification module 142 is a functional module of SDN controller 102 that includes a combination of hardware and software that allows SDN controller 102 to send an error message to the application when one or more flow capabilities 144 retrieved from storage module 138 fail to meet corresponding one or more flow requirements 146 retrieved from storage module 138. Notification module 142 can, for example, include one or more machine-readable storage mediums, such as medium 136, and one or more computer processors, such as processor 134.
In some implementations, notification module 142 can notify only the application without providing a corresponding notification to an operator, such as a network administrator. In some implementations, however, notification module 142 can include one or more output devices for notifying an operator. For example, in some implementations, notification module 142 can include hardware in the form of a computer monitor, related firmware, and other software for allowing the computer monitor to operatively communicate with other hardware of SDN controller 102.
For example, in some implementations, notification module 142 can generate instructions to display a notification on the screen of the computer module when one or more flow capabilities 144 retrieved from storage module 138 fail to meet corresponding one or more flow requirements 146 retrieved from storage module 138. Notification module 142 can be used to generate instructions to display other notifications on the screen of the computer module as desired, such as a notification identifying a flow requirement of flow requirements 146 that was determined as not being met by a network data path element, or a notification identifying specific network data path elements that support a specific flow requirement of flow requirements 146.
Notification module 142 can include other forms of output hardware and software. For example, in some implementations, notification module 142 does not include a computer monitor itself, but does include hardware in the form of a display port and/or video card. In some implementations, notification module 142 can additionally or alternatively include hardware in the form of a computer printer and/or printer port, related firmware, and other software for allowing a printer to operatively communicate with other hardware of computing system 132. Notification module 142 can further include a speaker, light, or other output device to provide audible, visual, or other notifications.
SDN controller 102 as depicted in
In some implementations, SDN controller 102 can include an I/O module to allow communication to and from SDN controller 102. Example of suitable I/O modules can include modules for monitors, printers, keyboards, mouses, styluses, touchscreens, speakers, etc. I/O devices for such modules can be connected to elements of SDN controller 102 via wired or wireless links.
Switch 106 can contain multiple ports 152, 154, 156, and 158 in operation with a processor module 160 and a storage module 162 to allow switch 106 to store instructions, respond to commands from SDN controller 102, and to forward network traffic to another network node connected to switch 106. It is appreciated that ports 152, 154, 156, and 158 can allow wired or wireless connections to other network devices in SDN 100. For example, in some implementations, one or more of these ports can be in the form of Ethernet ports. In some implementations one or more of these ports can be in the form of virtual ports.
Processor module 160 and storage module 162 can operate together to allow switch 106 to extract a set of fields from a received data packet to execute flow routing instructions or for other switch functions. Processor module 160 and storage module 162 can include one or more aspects of other modules described above with respect to
At step 172, node manager service 164 sends a request for table features to the added network data path element. For example, for an OpenFlow switch, node manager service 164 can send an OFPMP_TABLE_FEATURES message with an empty body to a newly added switch). At step 174, node manager service 164 parses a reply message from the switch. The reply message includes the number flow tables, flow capacities of each of those flow tables, the packet match and modification capabilities of those flow tables. At step 176, node manager service 164 updates a capabilities database 178 with a new set of tables and flow table max sizes associated with the added data path and at step 180 triggers a flow manager module 182. In the event that the SDN controller recognizes that a data path is removed (e.g., in certain conditions when an OpenFlow switch is removed from the network), at step 184, node manager service 164 can update capabilities database 178 to remove any tables associated with the removed data path. The above description outlines the exchange between one network switch and a controller daemon. This exchange when repeated with all data path elements in the network would result in population of a database that would be representative of the underlying SDN network's capabilities.
Flow manager service 166 runs a flow manager module 182. At step 186, flow manager service 166 queries for all the existing flows on every data path element identified by a data path ID by sending a request for flow statistics for a given data path. For example, for an OpenFlow SDN, flow manager service 166 can send an OFP_FLOW_STATS_REQUEST message). At step 188, flow manager service 166 parses the reply to the flow statistics request. At step 190, flow manager service 166 updates capabilities database 178 with information parsed in step 188, such as the current flow table free space. This can allow flow manager service 166 to determine the current free flow capacity available in each of the advertised flow tables of every data path element in the SDN network. At step 191, flow manager service 166 triggers an application applicability module for all applications. The application applicability module is part of application manager service 192 and uses the information in capabilities database 178 to determine whether a given application can be deployed on the SDN given the flow requirements collected for the application during registration of the application (see, e.g., application registration module 196 described below).
Application manager service 192 can be triggered by flow manager service 166 at step 180 described above with respect to
The application registration module 196 (which runs in parallel with application deployment module in this example) is triggered when an SDN application registers with the application registration service. Application Registration Module 196 exposes northbound interfaces for SDN applications to register themselves with the SDN controller service. The registration mechanism exposes a subscription policy for the application that may require an interested SDN application to provide the following registration fields about the flows that it intends to program on the SDN compatible network data path elements: (a) flow match fields requirement (e.g.: Match {source IP address, destination IP address}); (b) flow packet modifications requirement (e.g.: Action {Decrement TTL}); (c) types of egress actions required (e.g.: Action {Output: Port 20}); (d) number of such flows required per device (e.g.: 16,000 flows). At step 202, application manager service 192 reads registration fields from the SDN applications. At step 204, application manager service 192 parses the received registration fields. At step 206, application manager service 192 updates a flow requirement database 208 with the SDN application. At step 210, application manager service 192 triggers the application applicability module for the SDN application.
Apart from determining whether an SDN application can run successfully in the underlying network, an SDN application can subscribe to the SDN controller service for additional information. For example, such additional information can include: (a) a list of all flow tables in a given data path if multiple such flow tables could support the application requirement (e.g.: Flow Tables {100, 101, 102} in OpenFlow Switch X); (b) a list of data path(s) that do not support the requested application flow requirement on the network, if any (e.g.: OpenFlow Switches Y and Z); (c) Verification support for flows by programming sample flows onto the data path (e.g.: Program 1,000 flows of type [Match {source IP}; Action {Drop}] in Switch X and report any errors); and (d) data path verification of the Flows being installed (e.g.: Verify that Switch X drops traffic according to the OpenFlow rules programmed into it by this service).
An example use case for SDN controller service is provided below. It is appreciated that the example use case described below is not intended to narrow the broad description of the SDN controller service described above, but is instead intended to provide a specific example that implements aspects of the service. In this example, an SDN application App-A is installed on an OpenFlow Controller. App-A is a IP-QoS (Quality of Service) based application that requires an OpenFlow rule with the following Match and Action capability: (a) Match {source IP address, destination IP address}; and (b) Action {Set-field: Modify IP-Differentiated Services Code Point (DSCP), Output: NORMAL}. App-A further requires a scale of 1000 rules per device.
In this example, the underlying OpenFlow network consists of three network switches, switch X and Y from the same vendor (which have first and second hardware capabilities) and switch Z from a different vendor (which has a third hardware capability). When App-A is deployed on the Controller, it may be difficult for the network administrator to know whether all the underlying switches X, Y and Z can support the flow requirements of App-A without relying on the documentation of the switches.
In this example, switch Y in this example network does not allow a modify IP-DSCP action and Switch Z does not support a scale of 1,000 flows on the flow table that can support this type of flow. App-A, however, requires switches that can provide this functionality. In this example, any services offered by App-A relating to this functionality may be disabled, or App-A itself can return an error message. If a second SDN application App-B is planned to be installed on the same SDN controller, the administrator will need to separately determine whether this new application can be successfully deployed on the network. A similar situation will occur if a different model of switch is being added to the underlying network from a different vendor or if an existing switch is being upgraded to a different firmware which could potentially add more capabilities.
Through the use of certain implementations of the controller service described herein, SDN applications App-A and App-B would first register with the service and specify each of their flow requirements via a subscription policy. The service would then notify App-A that it cannot run successfully over the entire network since switch X can't support such an action and switch Z doesn't support the scale requirement of the application. Certain implementations of the disclosure provided herein can provide certain advantages. For example, certain implementations can provide a programmatic way for an SDN application to determine if its flow requirements can be met in the underlying network. Certain implementations can spare network administrators from having to manually test via trial and error mechanisms to check if a new SDN application can be deployed on the network. Certain implementations can provide run time notifications to applications if a network topology change causes the application to no longer work because its requirements can no longer be met on all the underlying SDN compatible devices. Certain implementations can provide suggestions on the best fit tables provided to SDN applications based on their flow requirements on each of the data path elements in the network. Certain implementations can provision data path validation of the flow signatures on the underlying switches in the network.
While certain implementations have been shown and described above, various changes in form and details may be made. For example, some features that have been described in relation to one implementation and/or process can be related to other implementations. In other words, processes, features, components, and/or properties described in relation to one implementation can be useful in other implementations. As another example, functionalities discussed above in relation to specific modules or elements can be included at different modules, engines, or elements in other implementations. As but one example, storage module 138 of SDN controller 102 can include aspects of comparison module 140 and vice versa.
As used herein, the term “provide” includes push mechanisms (e.g., sending data independent of a request for that data), pull mechanisms (e.g., delivering data in response to a request for that data), and store mechanisms (e.g., storing data at an intermediary at which the data can be accessed). Furthermore, as used herein, the term “based on” means “based at least in part on.” Thus, a feature that is described based on some cause, can be based only on the cause, or based on that cause and on one or more other causes.
Furthermore, it should be understood that the systems, apparatuses, and methods described herein can include various combinations and/or sub-combinations of the components and/or features of the different implementations described. Thus, features described with reference to one or more implementations can be combined with other implementations described herein.
Claims
1. A method comprising:
- accessing a flow capability database that contains flow capability information for flow paths along network data path elements in the control plane of a Software-Defined Network (SDN) controller;
- determining network compatibility for an application to be run on the SDN controller based on the accessed flow capability database and whether flow capability requirements for the application are met by a flow path; notifying the application when a determination is made that the flow capability requirements for the application are not met by a flow path; receiving, with the SDN controller, an indication that a network data path element has been added to a control domain of the SDN controller; querying the added network data path element regarding its table capabilities; receiving table capability information for the added network data path element; determining flow capability information for the added network data path element based on the received table capability information for the added network data path element; and storing in the flow capability database the determined flow capability information for the added data path element.
2. The method of claim 1, further comprising:
- querying each network data path element n the control plane of the SDN controller regarding its table capabilities;
- receiving table capability information for each queried network data path element;
- determining flow capability information for each queried network data path element based on the received table capability information for each queried network data path element; and
- storing in the flow capability database the determined flow capability information for each queried network data path element.
3. The method of claim 1, wherein the flow capability requirements include a flow match field requirement, a flow packet modifications requirement, a type of egress action requirement, and a number of flows requirement.
4. The method of claim 1, further comprising:
- receiving, with the SDN controller, an indication that a network data path element has been removed from a control plane of the SDN controller;
- updating the flow capability database to remove the flow capability information for the removed network data path element.
5. The method of claim 1, wherein the network data path elements are network switches.
6. The method of claim 1, wherein the table capability information includes information regarding the number of flows supported in a flow table for the network data path element.
7. The method of claim 1, wherein the table capability information includes information regarding whether the network data path element is capable of modifying metadata of a packet received by the network data path element.
8. The method of claim 1, further comprising:
- providing the application with a list of flow tables on each data path that support the flow capability requirements.
9. The method of claim 1, wherein the act of notifying the application includes identifying a flow capability requirement that was determined as not being met by a network data path element.
10. A Software-Defined Networking (SDN) controller comprising:
- a processor; and
- a memory including instructions that, when executed by the processor, cause the SDN controller to: store flow capabilities for flow paths along controlled network switches;
- store flow requirements for an application to be run on the SDN controller; determine network compatibility for the application based on whether a flow capability for a flow path accessed from the storage module fails to meet a flow requirement retrieved from the storage module; send an error message to the application when a flow capability retrieved from the storage module fails to meet a flow requirement retrieved from the storage module; request switch capabilities for a network switch that has been added to a control domain of the SDN controller; and store switch capabilities for the added network switch.
11. The SDN controller of claim 10, further comprising:
- a network port to communicate with network switches in the control domain of the SDN controller.
12. The SDN controller of claim 10, wherein the instructions further cause the SDN controller to:
- determine whether every switch requirement for each application to be run on the SDN controller is met by every corresponding switch capability for each network switch in the control domain of the SDN controller, and
- send an error message to the application when any switch capability fails to meet any switch requirement.
13. A non-transitory machine-readable storage medium encoded with Software-Defined Network (SDN) controller service instructions executable by a processor to:
- access a flow capability database that contains flow capability information for flow paths along controlled network data path elements;
- determine network compatibility an application to be run on the SDN controller based on the accessed flow capability database and whether flow capability requirements for the application are not met by network data path elements in a flow path;
- notify the application when it is determined that the flow capability requirements for the application are not met by network data path elements in a flow path;
- request switch capabilities for a network switch that has been added to a control domain of the SDN controller; and
- store switch capabilities for the added network switch.
| 20130250770 | September 26, 2013 | Zou et al. |
| 20130266007 | October 10, 2013 | Kumbhare |
| 20130329734 | December 12, 2013 | Chesla et al. |
| 20140052836 | February 20, 2014 | Nguyen |
| 20140089506 | March 27, 2014 | Naga et al. |
| 20140146674 | May 29, 2014 | Wang |
| 20140173018 | June 19, 2014 | Westphal et al. |
| 20140177634 | June 26, 2014 | Jiang |
| 20140226467 | August 14, 2014 | Park |
| 20140241247 | August 28, 2014 | Kempf |
| 20160065454 | March 3, 2016 | Arumugam |
| 20160218957 | July 28, 2016 | Liang |
| 20160344633 | November 24, 2016 | Jiao |
| 20170034005 | February 2, 2017 | Liang |
| 20180337848 | November 22, 2018 | Bhaskar |
| 103346922 | October 2013 | CN |
| 103795596 | May 2014 | CN |
| WO-2013104375 | July 2013 | WO |
- IQ.com search, NPL, Mar. 6, 2019 (Year: 2019).
- IQ.com search, Patent/PGPub, Mar. 6, 2019 (Year: 2019).
- “Software-Defined Networking: Why We Like it and How we Are Building on It,” White Paper, Apr. 10, 2013, pp. 1-4, Cisco.
- International Search Report and Written Opinion, International Application No. PCT/US2014/063836, dated May 11, 2015, pp. 1-9, KIPO.
- The Open Networking Foundation, “OpenFlow Switch Specification”, Version 1.3.0 ( Wire Protocol 0×04 ), Jun. 25, 2012, 106 pages.
- Open Networking Foundation, “Software-Defined Networking: The New Norm for Networks”, White Paper, Apr. 2012, 12 pages.
- Open Networking Foundation, “OpenFlow Management and Configuration Protocol”, OF-CONFIG 1.2, Version 1.2, ONF TS-016, 44 pages, published 2014.
- “Ryu—An open source OpenFlow controller” (webpage), available online at <http://osrg.github.io/ryui>, 2017, 2 pages.
- “CPqD/NOX 1.3 controller”, (webpage), available online at <https://github.com/CPqD/nox13oflib>, 2013, 2 pages.
Type: Grant
Filed: Nov 4, 2014
Date of Patent: Sep 3, 2019
Patent Publication Number: 20180337848
Assignee: Hewlett Packard Enterprise Development LP (Houston, TX)
Inventors: Abhay Bhaskar (Bangalore), Rangaprasad Sampath (Bangalore)
Primary Examiner: Benjamin H Elliott, IV
Application Number: 15/500,822
International Classification: H04L 12/721 (20130101); H04L 12/64 (20060101); H04L 12/751 (20130101);
