Before OpenFlow and software-defined networking popularized the notion of decoupling the network control plane...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
from data forwarding devices, there was Infoblox. Infoblox argues that its DHCP, DNS and IP address management (DDI) product suite was part of a decoupled control plane before OpenFlow came along. While DDI doesn’t make the traditional command-and-control decisions that an OpenFlow controller makes, the technology does possess some foundational capabilities that could make Infoblox and its fellow DDI vendors important players in the SDN control plane world. Stuart Bailey, founder and CTO of Infoblox shared his vision with SearchNetworking.com.
How does software-defined networking (SDN) affect Infoblox?
Stuart Bailey: Software-defined networking is a transformative economic shift from custom hardware to commodity hardware in the networking business. That's kind of like the end of mainframes and the transition to client computing on the PC platform. That means a different kind of budgeting profile, which will affect a customer's ability to obtain automated configuration and control from Infoblox.
Until now there have only been two classes of products articulated and understood in the [networking] market. One has been management, and the other is the boxes that touch packets. SDN signals that there is an emerging set of products and value center in the control plane. Infoblox has been a control plane company from day one.
I would say what's important in real-time control plane is information management, reliability, scale and providing the right level of abstraction to handle an emerging class of applications like big data and private cloud computing.
Will Infoblox get into the OpenFlow controller game?
Bailey: That will be driven by demand from our customer base. I can tell you there is a lot of interest [in SDN control planes] and that's driving our activity in the Open Networking Foundation and FlowForwarding.org. There are very specific SDN pain points that are emerging in our customer base around trying to virtualize platforms. Our VMware plug-in and our F5 load balancing managers are addressing specific SDN control plane pain points.
More on software-defined networking and the SDN control plane
Big Switch unveils its controller, SDN apps and an army of partners
IBM targets SDN application layer with its OpenFlow controller
HP expands its SDN switch line and offers its own OpenFlow controller
I think of us as foundational to the [SDN] control plane. To even begin the control story you need something that knows every endpoint on the network, so IP address control is essential. Our Grid technology is a scalable, trusted control plane, and there is certainly an opportunity for [SDN] solutions to come onto our Grid. Our Grid can be deployed in physical appliances or in data centers on virtual appliances. It's a distributed control plane. We look at IP address control and metadata like DNS names and DHCP as just table stakes to do the kind of automation needed. When we talk about flows to virtual machines, the endpoints of those flows are still defined by IP addresses. The events that cause applications to start sending flows on the network are captured in DHCP. So I have something on the network that is kind of like a heartbeat. Once I have that information on network elements, I can think about how they interact fundamentally, and think about programmatic control.
[As OpenFlow and SDN develop] we can make good decisions on the forwarding plane depending on what's available, but that takes time. And there is friction among enterprises about how they will buy and deploy network gear. There is still some discussion about how this standardized [SDN] control plane will emerge.
You're a a member of the Open Networking Foundation's Architecture and Framework Working Group. What's your view on that group's charter?
Bailey: This group's charter is to create some documents and frameworks to articulate to the market at large what is software-defined networking and what is the scope of it. What are the challenges and pain points it can address on the one hand, and what is the vision and direction? Where should standards efforts focus? Anything fundamental from a standards perspective is only successful if it's accelerating the ability of our customers to take advantage of Moore's Law.
That brings us back to how the SDN control plane leads to a commoditization of network hardware. Cisco and other ASIC-centric vendors would push back against that.
Stuart Bailey: Again, I liken it to the mainframe. This is more disruptive than server virtualization. The thing that is driving [network hardware communization] is the complexity of applications and the scale that's being demanded by applications. Software is how you can obtain that scale. To be able to solve that with custom [network] hardware doesn't make any sense. The mainframe lost to enterprises being able to take advantage of client-server architecture and democratized computing in the eighties. In niche areas you can still buy a mainframe today. Server vendors already sell commodity hardware at scale, so they already understand low-margin hardware.
Let us know what you think about the story; email: Shamus McGillicuddy, news director.