Does OpenFlow Make Sense in Enterprise Networks?

Today, networks are more-or-less deployed and managed physically, using device-level management tools and traditional technologies like VLANs. This approach has resulted in networks that are static and don’t respond well to changes. New connectivity and innovations that requires different policies and configurations takes a long time since those networks are too inflexible and can’t be adapted fast enough. Because OpenFlow-enabled solution allows users to manage the network more proactively and in a more centralized way the network can be more dynamic and responsive to business needs and less costly to administer. OpenFlow allows administrators to programmatically control the traffic flow with centralized controllers to dynamically provision and orchestrate the behavior of the network.

The short answer is that it’s probably too early to say what is genuinely possible, what might be truly optimal, and might ultimately be viable in the commercial context. There is an open question with OpenFlow, where the network takes on the roll of being the control plane and what implications this has for stability and reliability; much will depend upon how the standard evolves.
More broadly, as an industry we need to be supportive of attempts at creating standardized interfaces that simplify and/or improve the implementation and operation of evolving applications and data infrastructures; our open Fabric-based infrastructure for Data Center and Campus being a good proof-point of what is possible when interoperability is a key tenet. While OpenFlow has yet to reach that point where deployment into today’s real-world environments could be envisioned, we do see the concept of Software Defined Networking (SDN) as a logical development for the industry.

Virtualization of the network is finally enabling a paradigm shift away from traditional IT business models, but tighter integration between the network and the applications being transported by it is the crucial next step to removing organizational silos and providing a truly consumerized user experience in the business environment. As with any major shift, we expect to see technology alternatives appearing sooner than the general business population is ready to accept the cultural shift that accompanies this evolution. With that in mind, we are closely following this technology trend, while also exploring avenues for tighter integration of our own applications with the network; Avaya, being a multifaceted communications company, obviously has special interest in optimizing the end-to-end experience.

Joanie, let’s look at your question in two parts. The first part is does OpenFlow fit in with some of the megatrends in the industry? The answer is definitely yes. You mentioned server virtualization. What typically happens is that IT organizations take servers out of branch offices and put them into centralized data centers and then they virtualize them. IT organizations are motivated to do this to both save money, have better security and gain more control – in this case over their company’s data resources. I will suggest in a moment that those factors are also driving OpenFlow. Another burgeoning trend in the industry is desktop virtualization. With desktop virtualization, the applications are centralized and the user’s device could be a fully functional PC or a really dumb device. Again, a very similar situation with OpenFlow.

The paper on OpenFlow that is referenced at the top of this discussion (OpenFlow: Enabling Innovation in Campus Networks) makes the comment that “Virtualized programmable networks could lower the barrier to entry for new ideas, increasing the rate of innovation in the network infrastructure.” The paper gives a number of possible scenarios. As an example of the breadth of the paper, one is mobile wireless VOIP clients.

So, one way to look at OpenFlow is that it is like a hypervisor on one of the virtualized servers you mentioned and provides a new level of control and security. As you know, hypervisors provide a lot of really powerful management functionality and have APIs to hundreds, if not thousands of other companies (e.g., the massive size of VMWorld?) so that they can add value on top of OpenFlow. That is one potential advantage for OpenFlow – open up networks to a wide range of innovation and integration.

Another potential advantage for OpenFlow goes back to my reference to virtual desktops. When you virtualize your desktop and keep applications in a central site, you might keep a fully functional desktop or you might just use a really dumb device. It is possible to envision a world in which OpenFlow is widely deployed and switches and routers perform pretty much the way they do now. It is also possible to envision a world in which OpenView is widely deployed and switches and routers are just dumb, low cost forwarding engines.

OpenFlow is still in its early stages yet it holds a lot of promise in terms of addressing complexity in many of today data center networks. The challenges are particularly severe in large scale-out data center networks, such as cloud data centers, where issues such as multi-tenancy, virtual machine and service provisioning, security and traffic isolation are all very real challenges.

Being able to take these challenges, centralize the intelligence and manage the problem space from a single window pane via OpenFlow is particularly attractive. Interestingly, large service providers in the past have had similar network challenges. From complex forwarding and routing, to multi-tenancy, to service provisioning, these problems are not new. Carriers and services providers have traditionally addressed them through provisioning systems, but many of which were proprietary. Today one can think of OpenFlow as doing the same task in large data centers, but with promise of addressing the problems in a standardized manner with broad industry participation.

While there is a community that believes OpenFlow will lead to the instant commoditization of hardware, we believe they will be sorely disappointed. OpenFlow allows you to do some very cool things in the control plane, but at some point, something still needs to handle the duties of the data plane. Its also important to note that OpenFlow is extensible, so there will continue to feature differentiation in the actual forwarding hardware. Both of those facts add up to there being continued differentiation in data plane hardware. By the way, that is not just our perspective, Martin Casado recently expressed some similar sentiments on his recent blog: (Martin’s research helped lay the foundation for OpenFlow).

Finally, there is the unpleasant reality that data centers are heterogeneous environments, especially in the enterprise, and switching hardware must have the flexibility and extensibility to handle whatever technologies, old and new, get thrown at it.

From a Cisco perspective, one of the primary benefits of OpenFlow is breaking down the wall between applications and their underlying infrastructure and providing a programmatic interface to data center infrastructure. OpenFlow is put one aspect of the broader concept of software defined networks (SDN) which we believe will help reshape the evolution of networking be providing the programmability/extensibilty and closer coupling of application and infrastructure.