As you might have surmised, we’re using the NetFlix strategy on this series and instead of making you wait another week, you can binge read both posts at once—I know this isn’t quite the same caliber as Breaking Bad, and it’s not clear we have a Walter “Heisenberg” White of SDN today (hmm, maybe that’s a competition worth running, like our Turkey of SDN one), but at least we’ve saved you from one week of wait. Let’s get on with it.

(BTW, if you haven't read Part I, you should so so first.)

In the first part, I discussed the strategic importance of controllers in SDN,  the state of commercial controllers at major networking vendors and touched on the current state of open-source controllers. In this second part of the series, I discuss the nature of the new open-source controller battleground, especially with the entrance of OpenContrail from Juniper and possibly ONOS from ON.LAB.

What are the Main Differences between OpenDaylight, ONOS, and OpenContrail?

Of the list of open-source controllers discussed in Part I, if we examine the three controllers (ODP, ONOS and OpenContrail) that have captured recent mindshare in the world of SDN, it’s clear that there are different goals for each of them. Most telling is the foundational diagram used by each organization to explain their project (which I’ve reproduced below next to my analysis of each controller):

• OpenDaylight from the OpenDaylight Project – focused on becoming the one controller to rule them all—the über-controller. Architecturally, it aims to provide plug-and-play at all levels of its abstraction and tries to bring in as many pieces under its umbrella as possible. ODP ties together a wide variety of functionality from many vendors, from virtual network abstractions, to security capabilities, to traffic optimization, and it supports a variety of southbound interfaces through its MD-SAL (model-driven service abstraction layer). ODP today is primarily datacenter focused but there’s no architectural reason why it can’t service the WAN as well.

OpenDaylight Controller Architecture

• ONOS from ON.LAB – focused on Service Providers (SP) and WAN use cases in particular, presumably for traffic engineering at either large cloud providers like Microsoft or large SPs like AT&T. ONOS’ architectural focus is on fault-tolerance and state distribution across multiple controllers, as well as the higher-level graph abstraction of the overall network state, more so than being a single über-controller on its own, or attempting to accommodate multiple southbound or northbound interfaces. It’s easy to see why a service provider with large WANs would be enthralled by this design.

ON.LAB ONOS architecture

• OpenContrail from Juniper Networks – focused on network virtualization and service chaining with WAN integration. Primarily used in cloud environments to allow multi-tenant compute clusters with flexible networking domains supporting L4-7 service chaining. Architecturally built for centralized control but with distributed physical components for fault tolerance. OpenContrail is very routing focused and it’s unlikely that other southbound abstractions can easily be engineered into the codebase; similarly, its upper layers do not appear to accommodate multiple applications in the same way ODP provides for and looks closer to a single-purpose (network virtualization) controller designed for integration into other orchestration systems.

OpenContrail Architecture

In examining the controllers, Conway’s law (“organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”) certainly comes to mind, though in this case, I would postulate a slightly modified version (not quite a corollary), in that these three architectures clearly reflect the goals and aspirations of the organizations driving them:

• ODP – “Why can’t we all get along” – reflects the desire of the group to accommodate a diverse set of organizations, applications, protocols
• ONOS – “The United States of Controllers” – how to accommodate multiple controllers in a fault-tolerant fashion while orchestrating local controller actions in conjunction higher-level policies acting on global topologies
• OpenContrail – “Route, Route, Baby” – a very routing-centric architecture focused on solving multi-tenant cloud problems at service providers

And that’s why when I hear that ONOS and ODP can work together or collaborate, I'm a little suspicious. If you just examine the architecture of both projects, it becomes clear that it can only happen at a component-level or perhaps for ONOS to orchestrate multiple ODP controllers—which I don't see happening anytime soon. At the component level, perhaps ONOS’ Titan network graph DB component might be usable in ODP, and Zookeeper/Cassandra (or RAMcloud or other distributed state mechanism under consideration by ONOS) could be swapped for Infinispan as a state distribution mechanism—but the question would be why? What additional value would there be in doing so?

In the end, there’s certainly no comparing these three controllers across the same axes because of their divergent goals – we have apples, oranges and bananas here. They’re all fruits, but quite different in numerous respects.

How Might this Play Out in 2014?

ODP continues to lead: As we enter 2014, I’d expect ODP will continue to see large amounts of investment from various corporate entities (and not just the vendors that are members today)—it’s become the controller that you can’t ignore. However, ODP will probably see some rough patches while we all learn what it will take to have multiple competing applications trying to assert control over the same networking ports or flow. An appropriate allocation or conflict-resolution model for networking resources that is policy driven will have to be put in place within any multi-application, multi-tenant SDN controller. It’s unlikely we’ll see significant production deployments of ODP till 2015 and we’ll spend 2014 learning and adapting to the lessons learned from early POC (proofs of concept).

OpenContrail faces headwinds: As stated earlier, I expect that OpenContrail will see little uptake due to the single-vendor nature of the initiative. Ironically, the commercial solution will probably have traction in the marketplace.

ONOS is wildcard: And as for ONOS, it’s anybody’s guess—it depends on whether they can secure the corporate sponsorship they need to hire the headcount to execute the project successfully. Regardless, it will not be till late 2014 before ONOS is deployable in any kind of proof-of-concept environment.

Only Ryu sees continued investment: Looking forward, across all open-source controllers, I would expect ongoing innovation in ODP and Ryu (due to NTT funding and using it), and perhaps some activity on OpenContrail for some limited time. If there’s no traction from external entities in 6 months, I’d expect Juniper to stop investing. The other projects will see limited investment; for instance, Floodlight will probably not see significant new investment from Big Switch while they re-pivot into the whitebox world, and in the end, ONOS is a wildcard since it’s not been open-sourced yet.

Commercial controllers plod along: On the commercial side, I’m very interested in seeing what happens with Cisco and its controllers and how ACI plays out with XNC and Cisco ONE--that's still a murky picture in my mind. I expect NSX will continue its roll-out as VMware makes improvements to the product and HP will keep pushing its VAN. However, I see HP's VAN running into similar issues as ODP will on application-conflict, plus HP will have to deal with challenges on their SDN application store--pricing applications and revenue share for SDN apps are going to be tricky and $0.99 a flow isn’t going to work as well as it did for the Apple App Store. And I see other networking vendors aligning with ODP while pursuing their own ODP-compatible strategy internally, spawning eventual ODP++ controller variants.

What should Enterprises, Cloud Providers and Service Providers do?

For Enterprises and Cloud Providers, if you just need a network virtualization solution primarily for cloud computing use cases (like building out IaaS or PaaS platforms), it depends on the orchestration stack you are using. If you’re VMware-centric, you almost have to try out NSX first before looking outside of VMware since NSX provides a decent network virtualization feature-set. Cisco might be a close second since it’s one of the few virtual switches that can run inside VMware’s hypervisor.

If you are running OpenStack, or CloudStack, you should look at vendors like Juniper, Nuage, Midokura, PLUMgrid etc and use their semi-proprietary solutions – it’s just easier that way and you don’t really want to be modifying and tweaking your own SDN controller, especially when so many vendors have solved the problem.

For Service Providers looking to build out their SDN network testbeds to enable WAN traffic engineering or optimization, you will either have to wait for ONOS, or attempt to work with ODP on bringing a WAN component to the solution. Architecturally, ODP should extend to the WAN--I’ve seen demos of ODP working within DOCSIS environments at MSOs, so it certainly can be done--but will need work.

And for Enterprises, Cloud Providers and Service Providers, if you’re looking for a custom solution that none of the commercial or open-source controllers provide, then you have to decide the appropriate code-base to start with. My pick would be ODP right now because of the momentum behind it and the lack of any other strong options today. Of course, if you feel the itch to start from first principles, you could go back to NOX, POX, Beacon, Trema, Ryu and build up from there—but only if you have the resources and stamina to do so.

What should 3rd-party Application Builders do?

If you have a networking application and are trying to figure out which controller to build on, I would suggest the following:

• If your application is enterprise datacenter centric, then look at building on NSX, possibly Cisco ONE/XNC and perhaps ODP. Certainly, while HP might have a viable controller, the penetration of HP infrastructure in enterprise datacenters is minimal today.
• If your application is service-provider WAN centric, then you’ll have to wait, or look to ODP as starting point that will require significant investment.
• If your application falls into a different environment and a new use-case, e.g. enterprise campus LAN etc, then you will have to evaluate the environment and decide which controller is best. For example, if your application services the educational market, then writing an app on HP’s VAN might not be a bad start.

Closing Thoughts

I firmly believe that no controller will solve all the SDN problems we have. Just as we have tiny httpd, Apache Tomcat, Jetty, NGINX, Apache httpd etc for web-servers, as well as a variety of commercial Java App Servers, we’ll have a variety of controllers, each appropriate to the problem domain.

It’s possible that one controller could eventually mature to handle 60-80% of the common use cases, but that’s another 2 years out. I think we'll find that there are different controller architectures for different problems. We’re just beginning to understand the complexities of SDN and these early controllers will go through metamorphosis in the next 18 months as we encounter different challenges: OpenFlow packet_in DDoS anyone?, rogue unsigned applications, rogue signed applications, dueling SDN applications, race conditions between SDN applications, lack of RBAC etc etc). It’s the early days yet in the controller wars, and I happen to think that we’re still in the prequel and Episodes I, II and III haven’t even happened yet.

And finally, if after all this, you're confused, worried and distressed about what your SDN controller strategy ought to be? Well, you'd Better Call Saul! Or, feel free to engage me at @sdn_news or @WireRoy, or better yet, leave comments below the post!