The rationale for opening up more layers than just the control and forwarding planes in network programmability is to glean as much statistical and analytical information as possible from the router or switch so the programming application can make more specific decisions on network behavior and customization. That's how Cisco's Open Network Environment (ONE) programmability strategy was explained by David Ward, chief architect and CTO of Cisco's Service Provider division.
Key to making this happen, as reported previously, is the northbound API in Cisco ONE that shuttles counters, and analytics, and statistics from the routers to the programming applications. And OpenFlow alone is just not up to the task.
RELATED: SDN/OpenFlow has Cisco jumping
"Northbound APIs are going to be critical because that's what people are going to end up writing to," Ward said.
And it's the focus of SDN discussions at the IETF and ITU standards bodies. At the Open Networking Foundation, which is focused exclusively on SDNs? Not so much. They're focused on bulking up the southbound OpenFlow API and protocol, Ward said.
But information delivered to management applications by the northbound interface is vital to maintaining the stability and resiliency of large routers networks - like the Internet. It's vital today and it's been vital since ever before the Internet became a mainstream personal and commercial information and communications tool.
"We need to find a way for the Internet, which has been successful, to be augmented by these," Ward said.
"The thing I'm really trying to do with SDN vs. just OpenFlow is integrate it directly into the router control forwarding, all the different layers," he said. "I just don't see the Internet being replaced. I certainly don't see it being replaced by that architecture. OpenFlow has no ability to do topology discovery. It's Ethernet-based only. In straight switch-to-controller, there's no horizontal communication between switches, there's no horizontal communication in the forwarding plane, there's no horizontal communications between controllers; that's exactly what I'm doing day in, day out with dynamic routing protocols, OA&M and the rest in the control plane of the Internet today.
"OpenFlow's mostly being used as a remote procedure call," Ward said. "The controller calculates something or somebody wants to program something, the protocol itself is a carrier to bring that down to the router or switch. The architecture in OpenFlow today is directly analogous to permanent virtual circuits in ATM. You go link-by-link, hop-by-hop all the way across the network. You know exactly how that's going to scale, you know exactly what those problems are going to be - we lived through that 10-15 years ago."
That's not to say OpenFlow does not have use cases. OpenFlow purists like NEC and Big Switch Networks say they have found demand for its in financial and technology companies as a way to extend VLANs and increase the scale of virtualized data centers.
And Cisco, which demonstrated its proof-of-concept OpenFlow controller at this week's CiscoLive! conference, said the technology has found a home in academia and research as a way to conduct network 'slicing,' in which a shared infrastructure is segmented to contain traffic to certain segments.
Network programmability in general though, and Cisco ONE's onePK API kit has broader applicability, according to Cisco. For enterprises, a couple of benefits could be realized in VPNs and data centers with low latency switches, Ward said.
"(onePK) was demanded on the Nexus 3000 because people don't want to run ARP when there's a lot of VMs in motion," Ward said. "You can overcome the deficiencies in ARP and the stale data that's in ARP by just programming (VM-to-MAC/IP addressing) directly to the switch. It's a really straightforward and extremely useful reason to want to have SDN."
It can also reduce the time it takes for a service provider to provision a VPN to an enterprise, he said.
"Between a provider edge router and an enterprise edge router that's a managed VPN... at that link you need to learn BGP or OSPF to get the routes from the enterprise into the VPN and then distributed over BGP," Ward said. "The (enterprise) doesn't have an IT department that can learn those protocols. They do have somebody that can write an app that, when that link comes up can inject 10 static routes - kind of like a home-groomed dynamic routing protocol that they can run, they can operationalize, put into a VPN and BGP just distributes that route. That solves how fast a service router can roll out a managed VPN."
And again, key to the inner workings of onePK is the northbound interface.
"What we have done is open a northbound API that an application could say, I want a path between (X and Y) that meets these constraints," Ward said. "It calculates it, then pushes it down to (X) and (Y), and then a normal control protocol sets that up. I just invented soft PVCs for MPLS. We've integrated with the exact same control protocols that you have out there today. It seems incredibly useful to me: we can do this for data center backup, mobile backhaul, service backhaul, for any reason that we ever set up an encapsulated path or LSP ever in the past. We just didn't have a programmatic way to do it.
"It's really getting information out of the router," he said. "The fact that, I've never been able in the past to see transport layer, IP/MPLS trunking layer, VPN layer; to be able to answer a very simplistic question: which lambda does my VPN LSP go over? I can't tell you today. Nobody can really tell you today unless, in their NMS system, they've laid out that map."
And an as yet understated key element to Cisco ONE programmability is Cisco's UCS server platform. Hardware appliances for firewalling, load balancing, security, traffic shaping, etc., now tacking up rack space in the service provider POP or enterprise data center could be virtualized in software running on the UCS and tightly integrated into the onePK API set for routers and switches.
Cisco showed an example of this in the Cloud Connectors it announced this week at CiscoLive!
"The fact that we have servers and routers available in the portfolio means that now I can program those servers to hold the virtual appliances...that we're building," Ward said. "Now if I can...program load balancing and traffic redirection based on SDN or OpenFlow...I've got a cost-effective way to do it. It gives (cloud providers) the ability to just program that stuff up instead of racking and stacking more and more appliances and making the infrastructure more complex. They can now do service backhaul based on programmatic interfaces to select just the traffic they want. They can very rapidly spin up these services."
An even broader impact on the industry of SDNs and network programmability might be the transformation of networking hardware vendors themselves. Cisco has always said it was looking to bulk up its software prowess; now it has no choice but to.
And neither does anyone else.
"It's not necessarily going to make it simplistic," Ward said. "The level of expertise is now changing and I think networking companies are going to have to have a lot more software expertise and programming expertise potentially than they have. This also gives rise in the industry for new service and solutions companies to add more value than just sales, support, training... Now they can actually do some solutions and customization, so in the industry it's going to be quite lucrative for a lot of folks."
More from Cisco Subnet:Cisco Subnet bloggers on Twitter.Jim Duffy on Twitter