Only time will tell, but SDN could very well be the future of networking. It will drive innovation, allow for new competition, and decrease the time to market of new features in the network. Ideally, it will also drastically improve operational efficiencies with a suite of applications to more easily manage the network infrastructure. Doesn’t it seem obvious by now that the hardware and software that are now so tightly integrated for every vendor should be de-coupled?
In this post, I’m going to write about possible SDN applications that I’ve been thinking about for the past few days. It’s more thinking out loud than anything else, but I’m not talking about OpenFlow applications, but rather the next layer up, which will include the integration of applications between an OF/SDN controller and other existing or new applications located in an Enterprise Data Center.
I was initially thinking, what existing devices are aware of the overall state of the applications, systems, and security in a data center? What other controllers, head-end systems, and manager of manager’s are out there that could make sense to integrate with an OpenFlow controller to create a smarter network?
In this post, I’m going to write about possible SDN applications that I’ve been thinking about for the past few days. It’s more thinking out loud than anything else, but I’m not talking about OpenFlow applications, but rather the next layer up, which will include the integration of applications between an OF/SDN controller and other existing or new applications located in an Enterprise Data Center.
I was initially thinking, what existing devices are aware of the overall state of the applications, systems, and security in a data center? What other controllers, head-end systems, and manager of manager’s are out there that could make sense to integrate with an OpenFlow controller to create a smarter network?
Since the state of the network could now be centralized in a controller, the decisions on how to route certain flows can be dynamically changed based on operator’s preference and centrally managed via this controller. We will likely see new *flow protocols* over the coming years, some of which may be based on information coming from 3rd party systems (not just using destination IP Address to route). These are the systems that this post will cover.
The 5 applications I’ve thought about recently to integrate with the network via an OpenFlow controller are the following:
VCenter – or any hypervisor central manager. VCenter already has plug-ins to dozens of other applications, is aware of CPU, memory, and overall system utilization. It knows where the VM is and is very familiar with the state of the virtual network. Being able to modify total network state, physical and virtual, based on information coming from VCenter seems too logical for it not to be of value. Just think about any information Vcenter has – it can easily be integrated into a controller, matched against any set of Boolean conditions or algorithms and then executed to modify the network as needed!
Application Performance Management (APM) – Companies like OPNET, Compuware, Fluke, NetQoS that receive information via tap or SPAN ports are proactively looking at the state of applications on the network. They are monitoring end user experience examining each leg of client to server (web, app, db) transactions, looking at user, server, and network latency, bandwidth utilization, and some tools combine this with NetFlow and generic SNMP data. Applications are set with performance thresholds. Instead of being used as monitor/alert only thresholds, they too, can be used as triggers to execute dynamic network changes to increase network performance.
IPAM – When InfoBlox first joined the ONF, I was unclear on what their vision was. Although this is pure speculation, it now seems to make sense because InfoBlox solutions, ranging from their DHCP, DNS, and IPAM (DDI) product and their config mgmt solutions (NetMRI), will know where every node on the network is. This includes physical and virtual nodes. It will become easier to manage the MAC/IP/NAME and location of every node on the network. What IP address should a device get? What MAC address does it have? What switch port is that device plugged into? What if that device changes locations? By integrating InfoBlox applications (IPAM, etc.) with SDN controllers, all of that state information can be shared and it will increase the options available for flow manipulation and security on the network.
Security Information Event Management (SIEM) – without going into too much detail, the same holds true here for what was previously described for APM & IPAM. Integrating tools like RSA EnVision that have a global view of the security events occurring in a network with an OF/SDN controller, it will make networks that much more “self-defending!” Old marketing phrase, right? Maybe now it’ll actually come to fruition. We could also include AAA servers here for monitoring authentication attempts, etc. and the list can go on. Leveraging security information like this could allow an Enterprise to have an intelligent network wide dynamic FW & IPS.
Call Processor – such as an IP PBX or Call Manager that will in totality understand when voice and video calls are being set up. Integrating Call Manager with a Controller could yield a SDN-way of implementing optimized flows for voice/video along with Quality of Service for those associated flows. Think RSVP on steroids.
Those are just 5 out of an infinite number of applications that could integrate to an OpenFlow/SDN controller. Because there could be so many apps integrated in an SDN design, one could argue of the importance of a standard interface for this type of integration. Not me! I’m of the opinion the northbound API integration doesn’t need to be standard among the SDN controllers. The more open a controller is though, and the more applications that are built for that controller will only make the overall solution that much more valuable! I do hope each OF/SDN controller manufacturer develops good relationships with 3rd parties to create some mind blowing network applications.
We will also likely see companies dedicated on just creating OF/SDN applications that only integrate to one controller vendor’s solution. We’ve seen this in the voice world with companies like Metreos (later acquired by Cisco) that developed advanced UC applications for Cisco CUCM. IP Celerate is another that focuses on apps. They’ve been very lucrative focusing on applications integrating to Cisco’s voice solutions. Wouldn’t be a bad strategy for start-ups out there in the SDN space.
I really hope there is an application coming for “Unified Management” that will ease the network operator’s pain of managing 10s and 100s of nodes on the network. Applications to create mini virtual switches will also surely be seen as a result of de-coupling the hardware from the underlying network operating systems. That one has been referenced quite a bit from Big Switch Networks over the last several months.
While SDN is still in its infancy, the opportunities do seem limitless. I look forward to seeing even more companies focused on OpenFlow, SDN, and SDN applications. The strong will survive and those that do will likely be the catalyst of the networking industry, as virtualization has been for the server industry.
And no, I’m not saying networking needs a VMWare – just saying it needs a catalyst, which I do think VMWare was for the server industry! Does that make sense? :) For what it’s worth, that’s how I interpreted Big Switch’s post on their website. It is not about comparing server, memory, and networking virtualization at lowest engineering levels possible, although I did learn quite a bit in the explanations described here and here! If there are similarities in how they accomplish virtualization, great; if not, who cares? A catalyst is still needed.
-Jason
The 5 applications I’ve thought about recently to integrate with the network via an OpenFlow controller are the following:
VCenter – or any hypervisor central manager. VCenter already has plug-ins to dozens of other applications, is aware of CPU, memory, and overall system utilization. It knows where the VM is and is very familiar with the state of the virtual network. Being able to modify total network state, physical and virtual, based on information coming from VCenter seems too logical for it not to be of value. Just think about any information Vcenter has – it can easily be integrated into a controller, matched against any set of Boolean conditions or algorithms and then executed to modify the network as needed!
Application Performance Management (APM) – Companies like OPNET, Compuware, Fluke, NetQoS that receive information via tap or SPAN ports are proactively looking at the state of applications on the network. They are monitoring end user experience examining each leg of client to server (web, app, db) transactions, looking at user, server, and network latency, bandwidth utilization, and some tools combine this with NetFlow and generic SNMP data. Applications are set with performance thresholds. Instead of being used as monitor/alert only thresholds, they too, can be used as triggers to execute dynamic network changes to increase network performance.
IPAM – When InfoBlox first joined the ONF, I was unclear on what their vision was. Although this is pure speculation, it now seems to make sense because InfoBlox solutions, ranging from their DHCP, DNS, and IPAM (DDI) product and their config mgmt solutions (NetMRI), will know where every node on the network is. This includes physical and virtual nodes. It will become easier to manage the MAC/IP/NAME and location of every node on the network. What IP address should a device get? What MAC address does it have? What switch port is that device plugged into? What if that device changes locations? By integrating InfoBlox applications (IPAM, etc.) with SDN controllers, all of that state information can be shared and it will increase the options available for flow manipulation and security on the network.
Security Information Event Management (SIEM) – without going into too much detail, the same holds true here for what was previously described for APM & IPAM. Integrating tools like RSA EnVision that have a global view of the security events occurring in a network with an OF/SDN controller, it will make networks that much more “self-defending!” Old marketing phrase, right? Maybe now it’ll actually come to fruition. We could also include AAA servers here for monitoring authentication attempts, etc. and the list can go on. Leveraging security information like this could allow an Enterprise to have an intelligent network wide dynamic FW & IPS.
Call Processor – such as an IP PBX or Call Manager that will in totality understand when voice and video calls are being set up. Integrating Call Manager with a Controller could yield a SDN-way of implementing optimized flows for voice/video along with Quality of Service for those associated flows. Think RSVP on steroids.
Those are just 5 out of an infinite number of applications that could integrate to an OpenFlow/SDN controller. Because there could be so many apps integrated in an SDN design, one could argue of the importance of a standard interface for this type of integration. Not me! I’m of the opinion the northbound API integration doesn’t need to be standard among the SDN controllers. The more open a controller is though, and the more applications that are built for that controller will only make the overall solution that much more valuable! I do hope each OF/SDN controller manufacturer develops good relationships with 3rd parties to create some mind blowing network applications.
We will also likely see companies dedicated on just creating OF/SDN applications that only integrate to one controller vendor’s solution. We’ve seen this in the voice world with companies like Metreos (later acquired by Cisco) that developed advanced UC applications for Cisco CUCM. IP Celerate is another that focuses on apps. They’ve been very lucrative focusing on applications integrating to Cisco’s voice solutions. Wouldn’t be a bad strategy for start-ups out there in the SDN space.
I really hope there is an application coming for “Unified Management” that will ease the network operator’s pain of managing 10s and 100s of nodes on the network. Applications to create mini virtual switches will also surely be seen as a result of de-coupling the hardware from the underlying network operating systems. That one has been referenced quite a bit from Big Switch Networks over the last several months.
While SDN is still in its infancy, the opportunities do seem limitless. I look forward to seeing even more companies focused on OpenFlow, SDN, and SDN applications. The strong will survive and those that do will likely be the catalyst of the networking industry, as virtualization has been for the server industry.
And no, I’m not saying networking needs a VMWare – just saying it needs a catalyst, which I do think VMWare was for the server industry! Does that make sense? :) For what it’s worth, that’s how I interpreted Big Switch’s post on their website. It is not about comparing server, memory, and networking virtualization at lowest engineering levels possible, although I did learn quite a bit in the explanations described here and here! If there are similarities in how they accomplish virtualization, great; if not, who cares? A catalyst is still needed.
-Jason
RSS Feed
