More Details About The Cisco ONE Controller Announced
Cisco has begun further unveiling more details about the Cisco ONE controller, currently in early beta. The announcement, specifies new SDN applications and hardware support for a select few existing products and new ones like the Catalyst 3850. Also recently announced, is the new Nexus 6000 switching product, along with a NAM module for the Nexus 7000. The Nexus 6000 is 96-ports of 40Gb low latency data center switch. Lastly, the Nexus 1000v support for Hyper-V integration into Microsoft System Center VM Manager and VXLan gateway support, both calculated moves in high stakes, data center virtualization chess. The big announcement is the software and will be for some time to come. With the Open Networking Summit coming up in April, it isn’t far fetched to expect the Java open source controller from the “Daylight” multi-vendor consortium to be announced relatively soon.
Key Cisco ONE Controller Announcements
- A new Cisco ONE Software Controller supports a highly available, scalable and extensible architecture; the industry’s first multiprotocol interfaces with One Platform Kit (onePK) and OpenFlow; consistent management, troubleshooting and security features; and built-in applications that include network slicing functionality for enabling logical partitioning of network resources. In addition, the ONE Controller will interact with Cisco networking applications such as Custom Forwarding and Network Tapping.
- Expanded platform support for Cisco onePK developer environment with Nexus 3000, Nexus 7000 and ASR 9000.
- Solutions for overlay networks including Nexus 1000V support for VXLAN Gateway; Nexus 1000V support for Microsoft Hyper-V and integration with Microsoft System Center VM Manager; virtual Network Analysis Module (vNAM) for network analysis and monitoring of virtualized and oud geoud workloads
- Expanded platform support for OpenFlow with Nexus 3000, Nexus 7000, ASR 9000 and Catalyst 6500.
The Cisco ONE and OpenFlow
Cisco has publicly committed to supporting OpenFlow since its announcement of the onePK last year. In order to do flow based forwarding, it only makes sense for consumers to expect a common mechanism to interact with hardware. The value should be well up the stack, but to get a proper stack, software developers need a common set of primitives.
There are some glimpses of deployment strategies from Cisco. Anything other than niche cases appear to be leveraging proactive flow instantiation. Reactive models on the above diagram allude to embedded systems.
“We want to meet developers where they are—this is not a controller tied to any particular technology,” said Shashi Kiran, senior director of data center and cloud networking at Cisco. “OnePK can take advantage of our hardware features [but] OpenFlow needs to work against a more abstract switch model,” – EETimes.com http://eetimes.com/electronics-news/4406200/Cisco-packs-ASICs-at-40G–phbraces-OpenFlow
OpenFlow support will be delivered alongside the proprietary APIs through the onePK development kit, residing as firmware on the network device. Early OpenFlow agents are available under NDA on the Nexus 3000.
Cisco ONE Applications
Cisco and others developing OpenFlow controllers are all focused on delivering applications north of the controllers. This is the promise of SDN, applications and APIs to automate and manage networks more efficiently. OpenFlow by itself offers nothing other than a mechanism to have a blank canvas to instantiate forwarding. Applications are the key to provisioning this policy. Cisco joins a small group of vendors, with beta SDN controllers in early customer trials today. Cisco is openly discussing a hybrid approach to OpenFlow which should translate into native and OpenFlow pipeline integration. The hybrid SDN working group at the ONF appears to have disintegrated. This is going to leave much more of architecture definitions up to the community, not the pay community 1%ers, but the real community of architects and engineers who are dealing with real problems.
- In the onePK slide below, Data Plane instantiation are handled with OpenFlow.
Three applications announced
- Network Tapping – This has become the low hanging fruit in the OpenFlow controller market. Big Switch has a similar product Big Tap. This application was arguably conceived from the FlowScale project that came out of research and education. When matching traffic and adding an action it is fairly easy to add another port to the forwarding action. This should make those in the security blackbox market nervous.
- Custom Forwarding – Path steering is L2-L4 policy based routing on steroids. Traffic engineering today is carries significant management overhead for traffic classification and link coloring. Path steering using OpenFlow offers new tools to have granular control.
- Network Slicing – This is another unique space from commercial vendors to delve in to. This is flow based multi-tenancy. Setting up multiple flow spaces allows for a new form of network virtualization. The controller or slicer is now the arbiter of multiple tenancies instantiating flows. This concept came from the GENI R&E project from the FlowVisor application.
It is worth noting, that much of heritage of these applications source from academia and NSF funded projects. While at times research and education loses its way, it is encouraging to see such relevance again.
My Thoughts
Cisco appears to be split into two camps, hardware and software. The custom silicon path at some point will likely taper down over the next few years as general purpose usage, reserving custom ASICs for more niche applications. The ONE seems to be the chosen platform for Cisco’s future of networking.
Still in stealth is the Cisco funded Insieme. Presumably at some point, Insieme point be spun back in with a product. I think what comes out of Insieme should be software, but clearly Cisco is still going after the hardware differentiation for now. There will undoubtedly be a software component with that, how that will integrate into the ONE controller will be interesting.
One potential pain point is, the apparent absence of the Catalyst 3750-X in the supported hardware roadmap. The ONE controller was announced in June of last year, claiming support for the Catalyst 3750-X. That appears to no longer be the case. This will disappoint some, since that is an easy to come by switch, that would serve as early lab and POC development. Also, existing hardware support is important for many IT budgets. Lastly, there needs to be more POE enabled OF switches. Almost everyone to a tee, has top of rack OF enabled, DC switches with Trident+ chipsets, but the vendor support falls in half when it comes to edge switches with POE support.
The 3750-X product line is way to new to be written off as being capable of supporting OpenFlow. I am pretty sure, the HP 3500yl, has less hardware capability under the hood than the 3750-X and it has had a OF agent for almost two years now. It would seem investment protection is lacking in that product line, if SDN development on that platform has halted to presumably focus on the Catalyst 3850. I hope to see the 3750-X reappear. I have an inquiry in to Cisco on this and will update as I hear back.
Cisco will provide proof-of-concept OpenFlow v1.0 agents on the Cisco Catalyst 3750-X and 3560-X Series Switches. – Cisco Announces Open Network Environment to Unleash Application-Driven Network Programmability
Proponents of the networking industry putting proper abstraction layers in place argue that current constraints do not offer enough forwarding flexibility. The march up the networking stack for business aware networks requires more routing prefixes. The simplest conceptual method needs to be loosely agreed upon as a forwarding abstraction. That does not necessarily mean the best, since that often turns into never getting anywhere. “Good enough” worked in the x86 world and will also work in networking. That is the importance of OpenFlow.
Introducing software into networks will create more efficiency but will also create a great deal more complexity not less. For better or worse, the business requires more flexibility that can no longer be delivered with strictly monolithic devices. The foundation needs to be as simple as possible, in order to support the layers of software that will rest atop. It is easy for some to be flippant and dismissive of OpenFlow. I don’t by a car based on the wheels, but I tend to prefer my cars to have wheels. If not OF then what? Another 5 -10 years to amass support around the perfect wire protocol seems unlikely. Cisco at the very least is hedging their bets. Clearly there are some within Cisco taking risk and evangelizing evolution.
I have used this product in beta, obviously under NDA. I can say, I like it. Cisco is figuring out how to embrace an open wire protocol, while attempting to not commoditize their products. In order to start designing and architecting SDN networks outside of DevOps environments, consumers need commercial products, with commercial support. onePK is to OpenFlow what the FabricPath pre-standard is to Trill. That is added value and agile applications. Support the basics and add proprietary values in the form of network management and customization. Cisco did this remarkably well in the x86 market with UCS.
Another card yet to be played, that Cisco is holding is the well established optical BU. There are few companies that can run the entire L1-L7 stack. Optical integration represents programmatic bandwidth on demand.
Overall, Cisco has stuck to its commitment and stayed within the ballpark on its timelines of delivering its SDN strategy. Cisco is supporting OpenFlow in a controller, regardless of speculation, the proof is in the products. Times are changing and so is Cisco, this is another brick in the road to abstraction.
Additional Analysis
Cisco fills out SDN family with 40G switch -Network World
Cisco packs ASICs at 40G, embraces OpenFlow -EETimes
Completely agree with regards to the 3750-X. If they could support that platform, even if it means losing a network module slot (a bit like you can do Netflow with C3KX-SM-10G) to support it.
If that support comes, it might very well convince me to start investigating a lot more seriously (because we have a lot of 3750s out there and more to come.)
Hi Simon, I am glad I am not the only one that is pretty annoyed about that. Hopefully it comes back into the fold. It only makes sense if Cisco wanted to lower the risk of losing current customers as they transition into the SDN arena, one would think that helping us out with firmware.
Thanks for adding that, its important for them to hear the feedback, thats all it takes.
Respect,
-Brent
Great article Brent. Have you seen indication, or are you just hopeful that Cisco will reduce the use of custom silicon? Cisco is rather dogmatic on the topic and Insieme won’t change that from what I’ve heard.
About time on the Hyper-V virtual switch. This could be a big deal (and I haven’t seen many people talking about it).
It’s disconcerting that you see the solution as being more complex. Enterprises spend way too much manpower dealing with the current environments – if it’s not simplifying things, they should avoid it.
Cheers,
Stu
Hi Stu, I actually have a blog post on Hi Stu, appreciate the comments. Very thoughtful as usual.
I agree Cisco is pretty adamant that custom ASICs are their long term future but I find it hard to imagine that it is sustainable. I think the best way to predict the future of networking is to look at the past 20 years of computing since the micro-processor was born.
Abstractly, networking really never really evolved with computing. I think the economics and flexibility of general purpose processors will inevitably win out over the increasing cost and rigidity of custom ASICs. The more general purpose, the faster services can be written to leverage the hardware. Going to the foundry every time you need a new feature has created bottlenecks in new services. Those services typically reside on the periphery of the network. I do think the closer to the backbone as more traffic aggregates there will still be a place for custom hardware to do fixed functions, very quickly.
Circling back to Cisco specifically, I think they are feeling out how this new software business model will evolve before they are ready to consider those conversations. I have no doubt there are folks involved in Insieme that would like a pure SW play, of course assuming there is some sort of HW coming out of it (speculation). How that would link back to ONE. Bet there are probably lots of plan B’s, e.g. what did and didn’t work as IBM transitioned in the 80’s.
I probably should have elaborated more on the complexity, I have been meaning to write a post. Again, I simply look at it from the x86 evolution (one trick pony here). When a sys admin provisioned bare metal servers 10-15 years ago it was fairly complex or at least inefficient, image it, patch it, networking was a patch cable that either worked or didn’t, storage etc. The upside was that it was really easy to troubleshoot and operate. One nic, some disks etc. The downside was that it was really inefficient and capacity management was terrible. It was either at 1% or 99% cpu/memalloc.
Virtualization reversed all of that, provisioning is a piece of cake, click and provision a flavor of OS, P2V your bare metal etc. But, troubleshooting can be much more tricky. In order to have all of these lovely mechanisms for (de)provisioning and efficiently over-subscibing hardware requires new layers of abstraction. Abstraction layers are there to hide complexity with another layer and theoretically each layer abstracts a bit more complexity into something easy. Voila, we have Vmotion, one little feature from Vmware that managed to turn the data center upside down.
Networking is almost identical. Network operators today work pure magic, bending protocols to their will to do things that were never originally intended. So as we add layers of SW abstraction we will make the day to day operations more efficient and even easier (Vmotion) but with those layers in place so will it obfuscate problems. I dont think senior engineers will be debugging code nessecarily, but I do think they will need to really understand all layers, rather than the one mess of complecity we have today.
Whether MPLS/BGP, overlays or OpenFlow, they all bring their own complexities. The need is application awareness which will require L4 awareness, I like OpenFlows promise there because it makes is made up of L2-L4 and treats all of those tuples as just another header field with a value in it. I like overlays for the data center until we have hardware and solutions flexible enough to level the network. I like BGP/MPLS because it is there today. I use it in every data center design I do because it is the only network virtualization we have ever had that scales. In the end its time to stop cobbling legacy protocols together to try and find a short term fix to a long term problem and agree upon the simplest foundation, which I tend to lean toward OpenFlow on for now and get focused on creating applications to do the ridiculously complex things that the business needs.
Net is basic operations should be simplified and automated, but with layers always come complexity.
Wow, should have turned that into a blog post pal !
Thanks again for such thought provoking comments,
Respect,
-Brent
I thought I recognized that diagram from Paul Baran’s paper, interesting how we are coming back to the centralized vs decentralized paradigm again.
One needs to stay far away from the workplace to find a good and affordable
place to live. First of all, get familiar with the Advanced People Search function (which will make your life easier throughout your
job search). Newspapers and the media have been dominating our lives for
the past few weeks.