Network Management is dull. No excuses. Monitoring and interacting with the devices that move data from one location to another is a thankless undertaking that most of us building networks leave to an afterthought. Part of that is the complexity associated with managing networks. There are at least a dozen common methods for interacting with devices in the network including SNMP, CLI, AAA, Syslog, Netflow, and fancy XML/HTTP interfaces. So much variety breeds complexity so we tend to set our goals pretty low for interactivity with the network.
What if we had one common mechanism for interacting with the network? Different devices running different software would all speak a common language to the applications managing and monitoring them. Now what if that language was something the programmers writing those applications understood implicitly like an API library they could compile directly into their program? That would make interacting with the network as simple as making a procedure call within the application. That’s exactly what onePK – or the “one Platform Kit” – accomplishes.
Read More »
Tags: APIs, APM, application management, Application Performance Management, Application Visibility and Control, applications, AVC, Cisco APIs, deep packet inspection, Dynamic QoS, One Platform Kit, onePK, QoS, router, SDN, secret packets, software defined networking, video quality
Enterprise trends driving SDN and Network Programmability are becoming clearer. The skyrocketing number of virtual/cloud devices is making human configuration infeasible. A natural result will be that networks will move from being integrated based on physical box boundaries to being integrated based on software boundaries. Put another way, traditional box based network integration will be overwhelmed by device proliferation. Therefore businesses must adopt new approaches to device configuration and control. This will include a new layer of network software which will instantiate, orchestrate, and dismantle virtual networks.
But what does this really mean? Read More »
Tags: API, Borderless Networks, Cloud Computing, controller, Enterprise, intent, interface, onePK, partner, SDN, software, virtualization
This is the first in a series of posts about network based software development for “typical” enterprise developers, and how onePK can help.
Network based software development is special. The main interfaces are based on CLI interactions and SNMP, not to mention using RADIUS as a RPC mechanism, various forms of XML/HTTP found nowhere else, and additional innovations. For a typical enterprise or script developer these kinds of interfaces are unusual, to say the least. Read More »
Tags: API, developers, Network programmability, onePK, programmability, sdk
Programmability, application aware environments, and software defined networks are popular topics in the industry right now. Network operators see the revenue opportunities to deliver services which can dynamically utilize network infrastructure while meeting application specific requirements. This thought process dominated at this year’s Carrier Ethernet World Congress in Barcelona, and Cisco was helping lead the way.
It was a pleasure to watch some of our thought leaders share their unique and innovative ideas and direction with the larger service provider, vendor and analyst community – starting with Software Defined Networking (SDN). SDN wasn’t the only topic, we shared ideas around mobile trends such as 4G/LTE and small cells and the resulting network impact, the increasing need to marry the IP layer with the underlying transport layers, and strategies around moving legacy TDM services onto a packet infrastructure. I love watching the cross-industry creativity flow as we collectively solve today’s challenges posed by the growth of new user trends.
All that said, Read More »
Tags: Carrier Ethernet World Congress, Cisco, NPS, ONE, onePK, Open Network Environment, SDN, Service Provider, software defined network
For me, even though I am mostly a hardware geek, one of the coolest parts of the Cisco ONE launch at CiscoLive was the introduction of onePK. We see onePK as an core enabling technology that will have some cool stuff down the road.
So, one of the more common questions I get is about the relationship between onePK and other technologies related to network programmability such as OpenFlow (OF). Many folks mistakenly view this as an either/or choice. To be honest, when I first heard about onePK, I thought it was OpenFlow on steroids too; however, I had some fine folks from NOSTG educate me on the difference between the two. They are, in fact, complementary and for many customer scenarios, we expect them to be used in concert. Take a look at the pic below, which shows how these technologies map against the multi-layer model we introduced with Cisco ONE:
As you can see, onePK gives developers comprehensive, granular programmatic access to Cisco infrastructure through a broad set of APIs. One the other hand, protocols such as OpenFlow concern themselves with communications and control amongst the different layers—in OpenFlow’s case, between the control plane and the forwarding plane. Some folks have referred to onePK as a “northbound” interface and protocols such as OpenFlow as “southbound” interfaces. While that might be helpful to understand the difference between the two technologies, I don’t think that this is a strictly accurate description. For one thing, developers can use onePK to directly interact with the hardware. Second, our support for other protocols such as OpenFlow is delivered through agents that are built using onePK.
That last part, about the agent support is actually pretty cool. We can create agents to provide support for whatever new protocols come down the pike by building them upon onePK. This allows flexibility and future-proofing while still maintaining a common underlying infrastructure for consistency and coherency.
For instance, we are delivering our experimental OF support by building it atop the onePK infrastructure. For customers this is a key point, they are not locked into a single approach—they can concurrently use native onePK access, protocol-based access, or traditional access (aka run in hybrid mode) as their needs dictate. Because we are building agents atop onePK, you don’t have to forgo any of the sophistication of the underlying infrastructure. For example, with the forthcoming agent for the ASR9K, we expect to have industry leading performance because of the level of integration between the OF agents and the underlying hardware made possible by onePK.
In closing, you can see how extensible our programmatic support is with the ability to use onePK natively or to support technologies and protocols as they are developed and released. This gives customers a remarkable level of flexibility, extensibility and risk mitigation.
Tags: ASIC, asr9k, ciscolive, netconf, onePK, OpenFlow, SDN