I developed Intelligent Network (IN) services and platforms during the early 1990s. With IN, Unix based controllers were connected to traditional telephone switches to perform both obscure as well as massively deployed phone services. Some of these services had very large centralized routing databases controlling the ultimate trunk/path selection of calls. Read More »
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.
Part of the interest in programmatic interfaces is fueled by the desire to logically centralize network control functions. A global view of network state can have many benefits but it does not preclude the use of distributed protocols within the network. Network Programming Interfaces (NPIs) provide a facility to construct global state, mutate that state and distribute that state to the network which in combination with distributed protocols can aid in achieving greater network efficiencies, improve visibility, robustness and add to the value of the network overall. When used the right way, these NPIs will help set a new balance between centralized and distributed control. Key to this balance will be domain or deployment specific constraints. Read More »
So, goings on with OpenFlow and the Open Networking Foundation (ONF) are always lively topics for discussion. Since our announcement of Cisco ONE at CiscoLive, a number of folks have asked me if the announcement of our strategy changes our view of the ONF or the role of OpenFlow—the short answer is, simply, no.
We continue to strongly support ONF and its efforts related to SDN and our support has and will continue to been demonstrated in tangible ways. One of the elements of the Cisco ONE announcement is onePK, which is an enabling technology and one of the things it has enabled is the development of our OpenFlow agents. Similarly, we have introducing controllers and working with our customers to develop the technology.
What seems to surprise a lot of folks is that our contributions to ONF go beyond our own internal development efforts:
Technology Advisory Group – Chartered to provide high-level guidance on any technical issues faced by the ONF Board in which feedback is requested.
- Chaired by David Ward
Hybrid Working Group – Document the requirements for a hybrid programmable forwarding plane (HPFP).
- Chaired by Jan Medved
- Hybrid Use-cases document: Co-author: Bhushan Kanekar
- Hybrid Switch Architecture – Integrated: Co-author Bhushan Kanekar
- Hybrid Switch Architecture – Ships in the night: Co-author Dave Meyer
- Terminology document: Co-authors: Dave Meyer, Bhushan Kanekar
Beyond these two working groups, the Cisco folks, including Jan Medved, David Meyer, Josh Littlefield, Andrew Thurber, Alex Clemm, Mark Szczesniak and Bhushan Kanekar have been active in other workgroups including the Configuration & Management Working Group and the Extensibility Working Group.
Beyond these efforts, David Meyer has been a rock star across the board including contributions to the “OF futures” discussions and recently received an award from the ONF for his contributions.
To net things out, Cisco expects to be a pacesetter with regards to network programmability and SDN and our efforts with ONF will continue to be part of that strategy.
In the wake of our Open Network Environment (Cisco ONE) announcements, we are continuing our series on software defined networking (SDN) use cases, this time focusing on the primary use case for OpenFlow and universities, campus network slicing. If interested, a more detailed solution brief on this scenario and the Cisco SDN OpenFlow controller can be found here. And check out our demo video below.
University campus networks offer an increasingly wide array of networking services to one of the broadest user bases of any “enterprise.” Some universities have medical or high-security facilities and must maintain regulatory compliance accordingly. Student networking services vary depending on whether they are on or off campus, and in almost all cases students and faculty bring their own devices. Administration offices must also be able to manage the day-to-day activities of the university. Often event management must include the rapid provisioning of point-of-sale terminal support and back-end payment reconciliation. And faculty must have both data and video access within the university campus, across campuses, and further out to other universities.
As a result, the ability to partition networks (called “slicing”) based on SDN has risen in popularity. Although slicing is being performed today on isolated networks, the need to perform it on production networks is now becoming a priority. Cisco controllers and agents, as part of the Cisco Open Network Environment for network programmability, are aimed at addressing this need.
Much of the early research and collaboration between universities on OpenFlow and SDN has been driven by the adoption of National Science Foundation (NSF) projects such as GENI, an open, collaborative research environment to explore networking at scale.
One of the basic premises of SDN is that the abstraction of control plane management, out of each network device and into a centralized “controller,” can create high business agility through automation with relatively lower OpEx and low risk. SDN is a natural fit for the class of requests universities need to service.
One of the primary components to the emergence of SDN on campuses has been the ability to create logically isolated networks and allow them to be partitioned and programmed using slicing. In SDN, this is facilitated with an abstraction layer in the network device called a flowvisor. Today, many universities use flowvisors within their isolated networks in conjunction with SDN controllers to manage their slicing requirements. In many cases these slicing activities are still performed off the campus backbone, as the software used to implement both the operating systems and slicing functions does not provide the policy management consistency required for production network applications.