SDN: On Select Hardware Only?
To look at the IT trade press these days, you'd think everyone is on the fast track to deploying software-defined networking (SDN). In reality, much of this technology is still on the drawing board, with some estimating that truly workable production deployments are a good three to four years away.
This isn’t a bad thing, considering the crucial role networking will play in the virtual/cloud era. In an age of unlimited server and storage resources, the enterprise will live or die on its ability to move data from place to place.
To do that, of course, you’ll need a high degree of management and orchestration of newly abstracted network resources, which is one of SDN's prime advantages: the separation of control and data planes, allowing network configurations to be deployed and removed at a moment’s notice.
Ostensibly, this is all to be done in software, hence the term software-defined networking. Lately, however, it seems that some of the top platform vendors are intent on adding a hardware component to SDN, arguing that they can provide improved manageability through a more integrated approach.
First up is Cisco, which recently sent its OnePK system to beta users. The OnePK package features what Cisco calls elastic service control, which works across multiple hypervisors and non-Cisco switching platforms. So far, so good. However, Cisco is also employing specially designed ASICs on its own hardware, designed to give the vendor a leg up on defining and delivering service level agreements and implementing higher-order application control. It’s a gamble, really, assuming that enterprise users will value the extra edge that Cisco provides, despite the fact that SDN is designed to prevent just this kind of vendor dependency.
Meanwhile, Intel is taking a similar tack through a new set of reference designs for the development of SDN components, as well as a new Open vSwitch designed to smooth the flow of data across Intel-based hardware. The new switch reference design is a 48x10 GBE top-of-rack framework, while the server reference design offers up a common platform for virtual switches. Both support OpenFlow and Open vSwitch as well as numerous management APIs for third-party development; both are optimized for Xeon-based hardware. With this approach, Intel could hold major sway over the future development paths of SDN, even without producing any actual switching equipment or software of its own.
With SDN being such a recent development, however, the field is ripe for newcomers in software-based network management. Adara, for one, is counting on the enterprise’s need to unify management stacks under a single user interface as it rolls out the new Hercules platform. The system provides full orchestration and synchronization of SDN-based network elements, first by decoupling modular network components and then scaling them out to support large numbers of devices. In this way, Hercules provides a fully distributed, but still logically centralized, architecture. At the same time, it also provides an automated SLA enforcement mechanism, allowing highly dense VM configurations for multi-tenant environments.
Pica8 is out with the Open Data Center Framework that builds on the OpenFlow 1.2 protocol to provide a fully programmable network infrastructure. The system oversees three key SDN components – traffic engineering, tunneling and network taps – that Pica8 calls the building blocks of the network fabric. In this way, Pica8 strikes the opposite pose of Cisco and other hardware backers by saying a fully dynamic network environment can be accomplished in software using commodity hardware.
Ultimately, the choice is up to the enterprise, but hardware vendors' success in an SDN era will depend largely on their ability to provide value-added functionality to their pseudo-proprietary platforms. Either that, or we could be on the verge of another round of acquisitions, this time targeting network management software developers.