When it has broached the topic of software-defined networking (SDN) recently, Cisco has attempted to reframe the discussion within the larger context of programmable networks. In Cisco’s conception of the evolving networking universe, the programmable network encompasses SDN, which in turn envelops OpenFlow.
We know by now that OpenFlow is a relatively small part of SDN. OpenFlow is a protocol that provides for the physical separation of the control and data planes, which heretofore have been combined within a switch or router. As such, OpenFlow enables server-based software (a controller) to determine how packets should be forwarded by network elements. As has been mentioned before, here and elsewhere, mechanisms other than OpenFlow could be used for the same purpose.
Logical Outcome
SDN is bigger than OpenFlow. It deals not only with the abstraction of the data plane, but also with higher-layer abstractions, at the control plane and above. The whole idea behind SDN is to put the applications, and the services they deliver, in the driver’s seat, so that the network does not become a costly encumbrance that impedes business agility and operational efficiency. In that sense, Cisco is right to suggest that programmable networks are a logical outcome that can and should result from the rise of SDN.
That said, the devil can always be found in the details, and we should note that Cisco’s definition of SDN, to the extent that it might invoke that acronym rather one of its own, is at variance with the definition that has been proffered by the Open Networking Foundation (ONF), which is controlled by the world’s largest cloud-service providers rather than by the world’s largest networking vendors. Cisco’s understanding of SDN looks a lot more like conventional networking, with a distributed or hybrid control plane instead of the logically centralized control plane favored by the ONF.
This post isn’t about value judgments, though. I am not here to bash Cisco, or anybody else for that matter, but to understand and interpret Cisco’s motivations as it formulates a counterstrategy to the ONF’s plans.
Bog-Standard Switches
Given the context, then, it’s easy to understand why Cisco favors the retention of the distributed — or, failing that, even a hybrid — control plane. Cisco is the market leader in switches and routers, and it owns a lot of valuable real estate on its customers’ networks. If OpenFlow succeeds, not only in service-provider networks but also in the enterprise, Cisco is at risk of losing the market dominance it has worked so long and hard to build.
Frankly, there isn’t much differentiation to be achieved in bog-standard OpenFlow switches. If the Googles of the world get their way, the merchant silicon vendors all will support OpenFlow on their chipsets, and industry-standard boxes will be available from a number of ODMs and OEMs. It will be a prototypical buyer’s market, perhaps advancing quickly toward commoditization, and that’s not a prospect that Cisco shareholders and executives wish to entertain.
As Cisco comes to grips with SDN, then, it needs to rediscover the sort of leverage that it had before the advent of the ONF. After all, if SDN is all about putting applications and other software literally in control of networks composed of industry-standard boxes, then network hardware will suffer a significant margin-squeezing demotion in the value hierarchy of customers. And Cisco, as we’ve discussed before, develops more than its fair share of software, but remains a company wedded to a hardware-based business model.
Compromise and Accommodation
Cisco would like to resist and undermine any potential market shift to the ONF’s server-based controllers. Fortunately for Cisco, many within the ONF are willing to acquiesce, at least initially and up to a point. A general consensus seems to have developed about the need for a hybrid control plane, which would accommodate both logically centralized controllers and distributed boxes. The ONF’s braintrust sees this move as a necessary compromise that will facilitate a long-term transition to a server-based model. It seems a logical and rational deduction — there’s a lot of networking gear installed out there that does not support the ONF’s conception of SDN — but it’s an opening for Cisco, nonetheless.
Beyond the issue of physical separation of the data plane and the control plane, Cisco has at least one other card to play. You might have noticed that Cisco representatives have talked a lot during the past couple months about a “northbound interface” for SDN. As currently constituted, OpenFlow is a “southbound” interface, in that serves as a mechanism for a controller to program a switch. On a network diagram, that communication flows downward (hence southbound).
In SDN, a northbound interface would go upward, extending from the switch to the control plane and potentially beyond to applications and management/orchestration software. This is a discussion Cisco wants to have with the industry, at the ONF and elsewhere. Whereas southbound interfaces are all about what is done to a switch by external software, the northbound interface is a conduit by which the switch confers value — in the form of information intrinsic to the network — to the higher layers of abstraction.
Northbound Traffic
For now, the ONF has chosen not to define standard protocols or APIs for northbound interfaces, which could run from the networking devices up to the control plane and to higher layers of abstraction. Cisco, as the vendor with the largest installed base of gear in customer networks, finds itself in a logical position to play a role in helping to define those northbound interfaces.
Ideally, if programmable networks and SDN fulfill their potential, we’ll see the development of a virtuous feedback loop at the highest layers of abstraction, with software programming an underlying virtualized network and the network sending back state and other data that dynamically allows applications to perform even better.
Therefore, the northbound interface will be an important element in the future of SDN. Cisco hopes to leverage it, but more for the sustenance of its own business model than for the furtherance of the ONF’s objectives. Cisco holds some interesting cards, but it should be careful not to overplay them. Ultimately, it does not control the ONF.
As the SDN discourse elevates beyond OpenFlow, watch the traffic in the northbound lanes.
Twilight in the Valley of the Nerds 
Excellent post, as usual. You would think that hybrid model would almost be essential for a business resumption and resiliency standpoint but there are yet a lot of details to hash out.
Hybrid! SDN! INCONCEIVABLE! http://www.youtube.com/watch?v=G2y8Sx4B2Sk
Well, it’s not what I would call SDN, and I don’t think Cisco should call it SDN, either, but I understand completely why Cisco is espousing it.
Regarding this point: “Ultimately, [Cisco] does not control the ONF.”
That was one of the key reasons for the creation of the ONF. That is, there was a sense that existing standards bodies were under the collective thumb of large vendors. ONF was created such that only the ONF board can vote on binding decisions, and no vendors are allowed on the board. Done, right? Ah, well, not so fast. The ONF also has a Technical Advisory Group (TAG). For most decisions, the board actually acts on the recommendations of the TAG. The TAG does not have the same membership restrictions that apply to the ONF board. Indeed, the current chairman of the TAG is none other than influential Cisco honcho, Dave Ward. So if the ONF board listens to the TAG, and the TAG listens to its chairman… Who has more control over the ONF than anyone? https://www.opennetworking.org/about/tag
Pingback: For Cisco’s SDN strategy look North — Cloud Computing News
all these vendors attempts to bastardize the SDN movement centered around openflow into their own proprietary models is ridiculous. Every presentation at ONS has been about how the networking industry has fallen way behind primarily because of Cisco’s proprietary death grip. It has killed the networking industry, and if Cisco’s death grip remains, it will be the end of the network team … server guys will take over. Look at the vswitch, it completely killed Cisco in the access layer and now for most businesses it makes way more sense to implement network policy at the vswitch using tools the server teams normally control. Policy can only be efficiently operationalized with server tools because there are better tools to automate policy enforcement from windows and vmware. Nexus1000v is a weak attempt and the operational model to support it enforces silos not removes them. If the DC had good OF support and the network could enforce on workload, it would be a very elegant marriage that would facilitate a better technical and operational solution and enhance the teamwork between app and server teams by placing the naturally best focus for each role … but instead Cisco is trying to make the network the center of everything and it simply isnt going to work and is going to end up in the server teams running anything that has to do with creating real business value.Cisco’s “network is the platform” focus where every good technical solution must emanate from their overpriced box outward … rather than simply looking for what is best for the customer, will hurt them and all of the network engineers that blindly follow them. It should be this simple, when a user is created in AD, the policy is already entered once, that should be the only time that policy should have to be configured, ever. When an app admin installs an app and sets network and security parameters, that should be the only time these parameters should have to be configured, ever. If an app needs a network service, it should be able to access it and clearly a dynamic application network interaction can’t happen in any meaningful way without a centralized control plane. The good thing is that if AON and SONA provide any indication is that Cisco is absolutely clueless with intelligent and dynamic networking and their record of compolete and total failure in these attempts will hopefully show people they dont have to listen to Cisco on this, they really shouldnt. This reminds me of my scientific atlanta set top box where it is nearly impossible for me to find any show because the menu is so horrible … their developers are worried about how much better their new version is compared to their old version … where their customers are simply concerned with how much worse their crap is compared to what google and other web app developers are doing. This seems to be Cisco’s flaw … hopefully people can figure out the crap that Cisco is giving them is dismal compared to what is actually possible … and hopefully with the momentum from ONS other vendors can get the momentum they need to prove how much better networking could really be. The big problem has been that we give Cisco complete control over training network engineers, so its no wonder most do not have the skill set to understand any models other than Cisco. The simple reality is that ALL of the value that could and should be provided in the physical network has been moving to the applications who are figuring ways to work around how dumb the physical network is in software, if network teams dont figure a way around it soon, everything will be 100% overlay and the business value add of the physical network will be gone and the job of the network guy will be about as sexy as that of a janitor.
I’m guessing that Art Fewell is either a bored, out of work “blogging expert” or failed his CCNA test for the last time and has decided to take it out on this forum. Anyhow, I have worked (and still do) in both the Server and Network arenas since the early 90’s. I have no bias in regard to the direction networking technology will take. There have been a lot of good points made about Cisco’s greed and desire to maintain control of their markets. It can also be said that there is a natural progression toward SDN as more of everything is virtualized. However, to believe that one time configuration for user, application, and network is a dream, not soon to become reality regardless who controls the market. Virtual clusters will no doubt eventually integrate most if not all of their own networking needs into an SDN solution of some kind. BUT, at some point your data needs to leave that cluster, that building, and that site. Your clients want to connect to your cluster with wireless. You will always depend on hardware of some flavor to get connected and transfer data, and you’ll pay for it. If you’re not getting raped by Cisco, it will come in the form of licensing, support, and operational uptime. To believe that Microsoft or VMWare are any less evil than Cisco is just one cult versus another. They all want your money no doubt. If the argument is that it’s too difficult, well be careful what you wish for. If everything is eventually virtualized and made so easy that even Art can do it in a single operation, that sure to be followed by your job being outsource to China or India.
Pingback: Software Defined Networking Wakes Up: Analysis of VMware, Nicira, Oracle, Xsigo
Pingback: Software Defined Networking Redefined: VMware Buys Nicira, Oracle Buys Xsigo- Trend Cloud Security Blog – Cloud Computing Experts
Pingback: Software Defined Networking Redefined: VMware Buys Nicira, Oracle Buys Xsigo | Simply Security