In Part 1 of this series I outlined two of the more commonly accepted definitions of SDN. In this post I discuss how pure play networking vendors have tried to create solutions and package them as SDN.

Cisco announced onePK, a developer kit for their new Open Network Environment (ONE), which, in turn, they announced at Cisco Live this year. onePK is yet to actually be released as of this post. It essentially is a set of APIs that developers can use to interact with their Cisco gear instead of the Northbound and Southbound APIs that I referred to in Part 1. In the onePK APIs, an Open Flow agent can run in IOS, IOS XR, or NX-OS as speak with an Open Flow controller on the ‘north’ side and the openPK API on the ‘south’ side. As you can surmise, this leaves the Control Plane and the Data Plane still in the Cisco device. The reason for Cisco to do this are quite clear: Cisco feels threatened by SDN’s potential.

The biggest networking news item in 2012 was VMWare’s $1.26 billion acquisition of Nicira. Nicira was, after all, the pioneer of Open Flow and the SDN movement. People began to realize that after a decade of slow progress, networking was finally growing up. It manifested the networking industry’s readiness to keep up with server virtualization. However, that didn’t mean that VMWare started outselling Cisco overnight. Contrary to popular belief, the biggest revolution to hit the networking industry in the past five years is not Software Defined Networking. It is the advent of merchant silicon.

Merchant silicon is the reason why firewalls such as Palo Alto Networks, WAN Optimization Controllers such as Infineta, and data center switches such as Arista can exist. By using off-the-shelf silicon, they can deliver superior value by focusing on software. Pure-play giants like Cisco, who have invested a lot time and money in custom ASICs, are seeing their margins plummet because competitors can offer comparable value for much lower prices. Recently, Alcatel-Lucent outbid Cisco by $100 million to win a network infrastructure refresh project with the 23-campus California State University. Clearly trends like SDN, VM mobility, or DCI are not high priorities for everyone.

The insecurity that Cisco feels from SDN is the reason they want to to remain at the center of the ecosystem. With Cisco onePK, control remains on the Cisco device as Omar Sultan of Cisco describes. Thus, the controller that communicates with an Open Flow agent is quite different than the centralized controller envisioned by the Open Network Foundation (ONF). Cisco will make several announcements of other environments, platforms, and products that are iterative changes in reality to demonstrate that they are playing along. However, they will not release control of their market share by, for example, making a dumb switch running an Open Flow agent, and whose forwarding tables can be manipulated by standards.

In October 2012, Cisco acquired vCider as part of their SDN strategy, specifically to enhance their involvement in OpenStack. Of course, there is also a Cisco spin-off Insieme, now rumored at over 150 employees dedicated to building SDN solutions and platforms from ground up.

Brocade, another pure play networking giant, claimed their November 2012 acquisition of Vyatta was an SDN win. Brent Salisbury agrees. However, as Greg Ferro put it, the products are not SDN today.

In Part 3, I will wrap up this series of posts on vendors who have claimed SDN compliance by  discussing some vendors that focus on Services, such as WAN Optimization, Firewalls, and Load Balancers.

Software Defined Networking (SDN) has been around since 2011 or so and, along with network virtualization, is the networking industry’s response to server virtualization, which has been around for much longer. Despite being such a hot topic in forums, there is unfortunately a lot of uncertainty as to what SDN actually means, let alone what vendors promise to deliver. What SDN is depends on who you ask. It is comforting to know that at least the acronym is defined as the Security community has been calling for Security Defined Networking!

One of the more commonly accepted definitions of SDN is that it is the separation of the Control Plane and the Data Plane enabled by a centralized Controller. Under this definition Southbound APIs are needed between the Controller and the switches. Well known examples are OpenFlow and NETCONF. Likewise, Northbound APIs are needed between the Controller and the users. However, as Ivan Pepelnjak mentions, there are no Northbound APIs defined yet. Commercial (e.g. HP, NEC, and IBM) and Open Source (e.g. NOX and POX) Controllers already exist today. Whether they are actually shipping or have only been announced are defined on SDN Central.

Another way of thinking of SDN is that it is a programmatic way of isolating Virtual Overlay Networks from each other and from physical networks. In other words, SDN extends Virtualized Data Centers and Virtual Overlay Networks, thereby ensuring VM mobility in a scalable manner. (Overlay networks themselves are not new. The Internet itself started as an overlay layer to PSTNs. Ironically, fast forward a couple of decades and now VoIP is overlaid on IP networks.) Virtualized networks need overlays to support multi tenancy and VM mobility (elastic demand of virtual machines). Under this definition, the programmability that SDN offers can enable VM mobility in a flexible and agile manner. Common use cases of VM mobility are bringing up entire Data Centers during rolling brownouts, and being able to launch Dev Test environment on the fly.

As you can see, the definitions have nothing to do with each other. However, people try to find commonalities in them. In parts 2 and 3, I will detail the approach taken by some networking vendors to claim their SDN compliance.