The first day of NFD5, we visited Cisco, where John McDowall talked with us about onePK. onePK is a Software Development Kit (SDK) that allows developers to build software that can programmatically control and configure Cisco network devices. Customers want to the same control of the network that they have with compute and storage. Three languages are currently supported: C, Java, and Python.
[Note: I’ve noticed that Python is gaining a lot of acceptance in the SDN community and is why I recommended in The Virtual Network Instance that network people who are interested in SDN should learn the basics of Python programming.]
I find it interesting that Cisco is developing two APIs: the native onePK interface that exposes all the configuration parameters that IOS currently supports, as well as an OpenFlow interface. I didn’t hear anything about specific applications that Cisco is building or any work that they are doing with regard to defining new network abstractions that can reduce the complexity of network configuration and operation. It would be nice to know what abstractions they think will work well.
The deployment of onePK applications is very flexible, using any of three models:
1) Process hosting mode, in which the app runs in the network element;
2) Blade hosting mode, where the app runs on a blade within the network element;
3) End node hosting mode, where the app runs in a compute node.
(See more details about the deployment model on the Cisco Blog.)
This flexibility should allow the development of a distributed app that runs in both the network element and in an end node. The end node part of the app would have a global view of the network while the network element part of the app performs local processing. The local processing component provide fast response while the centralized component provides better optimization over the entire network. There was a Puppet+onePK example that worked as a centralized/distributed application. Cisco is building design guides for using onePK, which will help people get started.
There are a couple of interesting features that I’ve not yet seen in any of the OpenFlow documentation yet (they may exist and I’ve not seen them yet). One function is to detect the version of onePK in use. This is critical in networks where there will eventually be multiple versions of onePK deployed. Programmatically learning the capabilities of a network device is going to be critical to properly configuring it. The second thing is that when a network element needs to forward a packet to the controller, it attaches meta-data to the forwarded packet. The meta-data is used to multiplex the packet to the right onePK application, much like TCP port numbers do for network connections. I need to learn how OpenFlow performs these functions.
The onePK team is very focused on security. Applications must be signed in order for the onePK system to run them. Applications can be signed by a known vendor or self-signed by an organization. We didn’t hear details on how this system works and whether it applies to the OpenFlow interface as well as the onePK native interface.
onePK is a free software upgrade to existing platforms. Cisco plans to have 90% of their platforms supported by the end of 2013 and there is already support for many of the smaller switches. I looked at the onePK web site and it looks like you have to join the Cisco Developer Network in order to get access to the documentation and to download the software.
My take on onePK is that it provides access to the full functionality of IOS. In contrast, OpenFlow is based on a minimalist philosophy of providing the few critical functions that are required. Getting started with either one is still a good idea. As Cisco’s customers have stated, we need to have compute, storage, and network treated similarly, so that as workloads move, the network easily adapts.
Disclosure
The vendors for NFD 5 are paying my travel expenses and providing small gift items.
-Terry