Extreme Networks Takes The Open Road To SDN
Having announced that it was joining the OpenDaylight Project a month ago, Extreme Networks has come out with a software-defined networking strategy that will heavily leverage that open source project and that will also make use of the many assets developed by itself and Enterasys, which it acquired last September for $180 million.
That acquisition essentially doubled the size of Extreme Networks and made it into one of the several contenders that are trying to take bites out of industry juggernaut Cisco Systems and, to a lesser extent, Hewlett-Packard and Juniper Networks, who together have been the dominant suppliers of datacenter switching gear. Given its substantial presence in both datacenter and campus switching, Extreme Networks is putting together an SDN stack that takes both into account.
SDN is still in its infancy at this point, but it seems to be inevitable given the desire that all datacenters have to break the control plane from the data plane in their networks and to make traffic flow more programmable and the network more resilient because of this malleability. Extreme Networks is relying on the OpenDaylight SDN framework as a means of making networks programmable and as a platform on which to create network applications that will be portable across multiple stacks. This last bit is as important as the first bit.
Like other networking hardware and software suppliers, Extreme Networks could have just opened up its APIs and created a software development kit that allows programmers to link into network functions directly. This is, for example, what Cisco is doing with its Open Network Environment Platform Kit (onePK). Cisco has tied its Application Centric Infrastructure (ACI) controller very tightly to its switching hardware as well and lots of software and appliance providers higher up in Layers 4 through 7 in the network stack are lining up to hook into ACI. Not everyone will go with the ACI approach, of course, and so Cisco is hedging its bets and has created the Extensible Network Controller (XNC) that is based on the OpenDaylight controller, with some extra features added in (including support for onePK).
Extreme Networks has been shipping switches that support the OpenFlow protocol at the heart of the OpenDaylight controller for the past two years, explains Markus Nispel, vice president of solutions architecture and innovation at the networking company. The company has shipped switches with an aggregate of over 10 million network ports that can be part of its SDN stack. The XOS network operating system (a hardened variant of Linux designed to control switches) has OpenFlow embedded in it as a southbound API and OneFabric Connect extends XOS with a northbound API that already supports network applications from over 40 software partners.
The issue that Extreme Networks is trying to solve is one that has hounded the IT industry time and again: application portability. And an analogy from the server market that we discussed with Nispel is appropriate. Before the various Unix operating systems came along, systems had their own runtimes and APIs and applications were definitely not portable. An effort was made to equip Unixes with compatible APIs and file systems so that applications could more easily be compiled on various platforms, but there was never true application portability. Then along came Linux, an open source operating system that was ported to all of the major server platforms, and application porting became just a little bit easier. OpenDaylight, as we have said many times before, want to be like Linux for the network stack, allowing for the software to control many different kinds of networking gear and allowing for network applications to run in conjunction with any ODL-compatible controller.
“We have seen an evolution of different SDN architectures,” explains Nispel. “The initial controllers in the market were centered around the OpenFlow protocol from the Open Network Foundation, and while the protocol itself is a key component in our architecture, it is not the only component. A few years ago when the ONF came up with OpenFlow, they really focused on the protocol specifically, but they really left it wide open on how network applications can talk to the OpenFlow controller. And this had led to a market that is pretty fractionalized, and applications running atop OpenFlow controllers today are not really portable across those controllers.”
The SDN strategy at Extreme Networks is to participate in the OpenDaylight Project and bring its wired and wireless networking experience to the project to help shape the ODL stack. The company is also unifying its Xkit and OneFabric Connect API development efforts, which come from the two halves of the company, into one community called Connect Central with the ultimate goal of providing an application marketplace for applications to run along with the ODL stack. Extreme Networks is also going to stretch its SDN outside of datacenter switching to include branch office and campus switching, and wireless as well as wired LANs. Because Extreme Networks is supporting OpenFlow as the southbound API into the switches, its hardened ODL stack will be able to work with both its own gear and those from third parties that also support the OpenFlow protocol.
Generally speaking, any Extreme Networks switch sold since 2009 should be able to hook into the ODL stack. Nispel says that a typical datacenter customer upgrade cycle for switches has been on the order of five to seven years, and in some cases, customers even hold out as long as eight years. But the advent of SDN and the need for more bandwidth by all kinds of applications might be accelerating the switch replacement cycle. OpenDaylight still has some maturing to do, as did the Linux operating system and as still does the OpenStack cloud controller, but with so many heavy hitters in the networking space lining up behind OpenDaylight momentum is building for this SDN stack.
And customers are responding as well. “Networking teams at customers in some cases have not been as innovative as they should be, but obviously on the server side virtualization has changed the game in terms of the speed at which new services get deployed. The network teams had a hard time following, and they are coming to the realization that they have to do something or the server administration teams are going to eat their lunch.”
Every case will be different and pricing for SDN software is evolving, but Nispel provides some guidance that suggests customers should expect to pay a premium of between 10 and 25 percent over their network hardware costs for SDN functionality. To come up with this figure, Nispel cites market statistics that suggest the market for SDN-capable switches will reach between $2.7 billion and $3 billion by 2017, and this represents about 10 percent of the aggregate revenue in the switching market. Of that SDN-capable slice, somewhere between $400 million and $600 million in revenues will be for the SDN controllers, network applications that ride atop the controllers, and services. If a networking vendor is trying to charge more than that for SDN functionality, you are probably paying too much.