Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cisco Describes SDN Strategy, Sets Industry Back 10 Years

At Cisco Live on Tuesday, David Yen, SVP and GM of Cisco's data center technology group, and a supporting cast finally described Cisco's response to the SDN craze. Cisco's message was crafted to detail a highly useful direction for the Cisco faithful, and at the same time shows the company taking a deeply defensive position against the possibility that the technology could disrupt the networking leader's number one position in switching and routing.

Cisco's core proposition is that while the industry is abuzz with OpenFlow and SDN, what customers really want is programmability of the network. So, while OpenFlow and SDN are important developments, the real thing that will get customers excited, according to Cisco, is exposing all that intelligence that's already in the network and letting users program it. Rather than dealing with BGP and VLAN setups, just tell the network you want a connection between point A and point B, and describe your SLA. The underlying network will do the rest.

To that end, Cisco is offering onePK (or One Platform Kit), which is a software developer's kit that gets at a consistent set of APIs exposed on all of Cisco's current operating systems, IOS, IOS-XR and NX-OS. While onePK is only marginally related to SDN, it is, nonetheless welcome, particularly for all Cisco shops and those who've tried to develop networking management systems without such access. The lack of good API access has left network management vendors to use SNMP interfaces, which were not always well documented and varied across products. As a result, network management products have been hamstrung, leaving them to be little more than network monitoring applications. Now, with onePK, at least in an all Cisco environment, network management applications will have a shot at doing some serious management.

Cisco And Open Protocols

Cisco also announced support for OpenStack and OpenFlow. For OpenStack, which describes how to get servers, networking, and storage systems working together in a private cloud environment, Cisco will create the necessary APIs for the Nexus switches to participate in an OpenStack environment. Cisco also says it has some unnamed extensions in mind for OpenStack. For OpenFlow, which exposes a networking device's forwarding tables to programming by an outside controller, Cisco said it would support the standard, but primarily for the use of universities engaged in protocol research.

Of these two announcements, Cisco's OpenStack support appears to be quite sincere. Cisco seems to see OpenStack as a viable approach for use with its UCS servers. Cisco's joint venture with EMC and VMware, called VCE, is also a proponent of OpenStack. Cisco's rivals here, IBM and HP, are also both OpenStack adherents, which bodes well for the standard, and probably left Cisco no choice but to jump onboard.

What SDN Promises

So that's Cisco's view of customers want. But it's certainly far from the full story. One of the tenents of SDN is that it doesn't make a lot of sense for every single networking device to have all the smarts necessary for it to do its job. In fact, because of autonomous nature of switches, they can end up making forwarding decisions that might make sense to it, but are simply bad choices further down the road. A reasonable analogy is driving to work. You go the same way every day, but if three lanes of a four-lane road are closed one day, it would have made more sense for you to go a different route. If there was a central controller helping you--think of your navigation system, or Google Maps on steroids--you'd end up taking a better route that avoided the problem. The central controller has turned out to be a better way to manage wireless networks, where congestion or spectral noise can frequently cause localized problems.

  • 1