Cisco Blogs


Cisco Blog > Architect & DE Discussions

Virtualization, SDN, and Radically Simplified Operations

January 2, 2013 at 8:37 am PST

Today many look to SDN as the next big revolution in Networking.  But why is there such hype?  What radical change in the economics of networking will shift the industry?  The answer is Virtualization.

Virtualization’s growth is still in its infancy, and many aspects remain unexplored.  Still there are aspects of which we are certain:

  • With an explosion in the number of Virtual devices, it is unaffordable for humans to remain in the loop for routine network operations.
  • Emerging business models are not achievable when (slow) humans are involved in the provisioning process. Read More »

Tags: , , , , , , , ,

SDN: Are We There Yet?

October 19, 2012 at 11:12 am PST

True Story:  When my son was about 3, I took him to go see his first movie  in an actual movie theater.  They had just built a brand new theater near our home and he was suitably impressed with all the bright shiny lights.  Anyway, we got our popcorn and grabbed our seats just as the lights were dimming (you never really go anywhere quickly when an inquisitive toddler is involved). We got through the movie trailers, then, to my surprise, my son popped out of his seat and said he was ready to go home.  Being his first movie-going experience, he thought the trailers were the big deal and did not realize we had not yet gotten to the featured attraction.

I was reminded of this after watching some conversations around SDN and programmability unfold over the last few days.  If you believe to some of the folks out there, SDN is a settled matter--the technology is done, use cases nailed, and winning vendors already crowned.  All that’s left is for the janitors to sweep the popcorn off the floor.

Read More »

Tags: , , , ,

History as a guide to SDN’s coming evolution

August 8, 2012 at 1:34 pm PST

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 »

Tags: , , , , ,

Cisco onePK Plays Well With Others

August 2, 2012 at 2:05 pm PST

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: , , , , , ,

Distributed? Centralized? Both?

July 13, 2012 at 2:15 am PST

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 »

Tags: , , , ,