Introducing OpenStack and virtual network support for Floodlight

For anyone even remotely following cloud infrastructure, its been hard to avoid the collision of OpenStack, OpenFlow, and Software-Defined Networking.  In less than two years, OpenStack has grown to a community of over 180 companies and over 3000 active developers, offering Apache-licensed software for building public and private clouds.  Over the same two years, OpenFlow and SDN have seen similar growth.  The Floodlight controller has been downloaded over 5000 times since its launch in January and the Open Networking Summit this past April attracted over 900 attendees (with several hundred more on the waiting list).

Simultaneously, Quantum, a networking-as-a-service module, has emerged in the OpenStack ecosystem.  Quantum offers a plugin architecture through which multi-tenant virtual networking can be connected in OpenStack.  The new service has reached incubation status in the “Essex” release and will be promoted to being a core project in the “Folsom” release in several months.  In fact, a couple plugins offering open source SDN services, like Ryu, have begun to spring up as well.

Continue reading »

An Open Source Foundation for SDN

Now that things have settled down since we launched Floodlight several weeks ago, I finally had a moment to step back and reflect on the state of the open source ecosystem for Software-Defined Networks (SDN).  It struck me that with Floodlight and open vSwitch (ovs), a multi-layer virtual switch, developers and network administrators have all the tools they need to build an SDN for virtual machines based purely on open, Apache-licensed, production quality components.   In fact, we just completed a full battery of integration tests between floodlight and open vswitch to make sure this is possible.Why am I so excited by this?  That question probably requires a bit of background.  One potential architecture for an SDN involves a central controller managing a number of open vswitch’s (1 or more per virtualized host), allowing them to transmit traffic over a physical network using various tunneling technologies.  With a handful of caveats, this architecture can enable the kind of flexibility SDN requires and support a wide range of new applications.  And it’s possible to build it today. Right now in fact.  Using purely open source technology.  That’s a huge step forward from where SDN was a few years ago.

So, what’s next?  Well, the above architecture is a good solution for a fully virtualized environments but it does have a few drawbacks.  First, virtualization penetration is somewhere in the 40% range according to study by Veeam.  Its growing but with the easiest workloads virtualized, it will be a long, long road to 100%.  So, to cope with both the reality of physical servers and physical devices, SDN needs a few more pieces — most importantly physical OpenFlow-enabled switches and support in Floodlight for these switches.  A number of vendors, most recently HP, are beginning to release hardware and we’re working hard with Floodlight to support all these variants as we get access to them.  In fact, there is an exciting project called Indigo, offering open source OpenFlow-enabled firmware to accelerate physical switch adoption.  Overall, we are making great progress here but its going to be an ongoing process as the ecosystem evolves.

The second limitation of the tunneled vSwitch architecture is the physical network itself.  Someone still has to configure, manage, and maintain the tunnel over which a virtual switch tunnels.  In fact, they would be doing so with even less visibility into network traffic due to the tunnels themselves, making things like traffic shaping difficult to impossible.  At the end of the day, all traffic, both tunneled and non-tunneled, needs to traverse the same physical infrastructure and requires configuration and management.  In this case, it would seem SDN would make the network admin’s job harder instead of making it easier.  That is obviously not the goal…

An optimal architecture, one that truly unlocks the promise of SDN, involves extending management beyond the virtual domain to the physical edge of the network. This would allow Floodlight to better manage the network and provide ultimate flexibility to network applications.  The networking administrator could work hand in hand with a virtualization administrator to control datacenter infrastructure.

Obviously, this is a bit of a long view but that’s the kind of future I’d love to see open source enable for SDN.  We’re glad we completed our testing with ovs and Floodlight — its a great incremental step, and now we’re on our to tackling the entire network.

Why Apache is important to Openflow

As everyone in the networking world knows, OpenFlow has developed a nearly unstoppable amount of momentum.  It began as an academic tool for segmenting networks and is currently thriving in academia and campus environments.  It’s finding its way into cloud providers, entering the datacenter, and emerging as the defacto communication protocol for Software-Defined Networking.  In fact, a number of switch vendors like Cisco, Juniper, and IBM have made announcements about supporting the protocol in their switches and routers.As open source advocates and developers, we’ve spent a lot of time thinking about how we can turn this momentum into ubiquitous OpenFlow adoption.  In looking at the controller landscape, it became obvious that OpenFlow needed a professional quality, truly open controller platform that could support both academic and commercial interests.  This is why we created the Floodlight OpenFlow Controller and chose the Apache license for it.Why is Apache so important for Floodlight and OpenFlow?  As OpenFlow makes the shift from academia to industry, it’s important to offer a truly free, open development platform that does not place any limitations on how OpenFlow is used or commercialized.  A liberal open source license will play a key role in fostering innovation in a startup ecosystem, attracting key industry players, and easing enterprise adoption.

Lets look at two of the most popular open source projects today, OpenStack and Hadoop.  OpenStack was created by Rackspace and NASA under and Apache license and has spawned an ecosystem of over 140 companies including  startups like Nebula, Piston, Cloudscaling, Stackops, and major players like Rackspace, HP, and Citrix.  Hadoop, created by Yahoo and also offered under an Apache license, has a huge ecosystem including Cloudera, HortonWorks, Mapr, Datameer, Platfora, Karmasphere, Hadapt and has been adopted by virtually every large scale internet company.  In the cases of both Hadoop and OpenStack, the existence of a high quality, flexibly licensed reference platform has spurred a tremendous amount of innovation.

Even beyond fostering a startup and vendor ecosystem, there is actually concrete data that enterprises prefer adopting Apache licensed projects.   A survey by OpenLogic released in May 2011 found that 69% of open source applications are licensed under the GPL but GPL projects represent only 9.5% of open source applications used in the enterprise.  Flexible licenses (Apache, MIT, BSD) on the other hand represent 36.6%.  Kim Weins, senior vice president of marketing for OpenLogic, went on record saying that “open source developers choosing more liberal licenses will lower the barriers to enterprise adoption.”

While OpenFlow has achieved some great successes so far, it has the potential to fundamentally transform the networking industry just as Hadoop is tranforming data analytics and OpenStack is transforming cloud infrastructure.   Realizing this potential will require openness in just about every dimension — open working groups, specifications, and high quality, flexibly licensed open source tools.  This is why we are so happy to make Floodlight available under the Apache license.

Check out NodeFlow – a Node.js-based OpenFlow Controller

Last week, I officially announced the release of Floodlight, a Java-based OpenFlow controller, and as you might imagine, I’m always interested in new developments in the world of OpenFlow and Software-Defined Networking.  After all, projects that make SDN development easier and more accessible to a large pool of developers are essential to the emergence of an application ecosystem.


That’s why I wanted to mention NodeFlow, a Node.js-based OpenFlow controller.  Node is a fast, lightweight, and efficient server-side javascript platform based on Google’s V8 runtime and its gaining a lot of developer momentum.  While I haven’t spent a lot of time with NodeFlow (I’ve neither contributed to it nor talked with the author), it struck me as a great project and a great way to expand the community of SDN developers.

So, if you have a minute, check out NodeFlow!



Announcing Floodlight: An Apache-licensed OpenFlow Controller

We are incredibly excited to announce the release of Floodlight, a Java-based, Apache-licensed OpenFlow controller. Floodlight was created by the team at Big Switch Networks as a high quality open source controller that will form the foundation of a Software-Defined Networking (SDN) platform.What’s compelling about Floodlight?

  • Apache license – Floodlight is one of the few controllers available with truly flexible licensing terms.
  • Professional-quality toolchain – Floodlight inherits a growing list of build and debugging tools developed by the folks at Big Switch Networks.
  • Ease of use – Floodlight is written in Java, can run just about anywhere, and is accessible to even novice Java programmers.
  • Open community – Floodlight is developed by an open community of developers.  We welcome code contributions from active participants and we’ll openly share information on project status, roadmap, bugs, etc.
  • Testing and robustness – We are testing Floodlight against a number of physical and virtual OpenFlow switches in real network environments.
  • Help and Support – Many of us at Big Switch Networks are active on the Floodlight mailing list and happy to answer questions and offer advice.

Floodlight emerged from the Beacon controller, a project created by Stanford student and Big Switch Networks alumnus David Erickson, which recently changed licenses to a modified GPL license.  While we saw the Beacon core as an obvious leap forward in controller technology, we had a vision of creating a unified platform for OpenFlow development — one easy enough to be a learning tool, powerful enough for advanced research, and flexible enough to support commercial objectives. After all, part of the power of OpenFlow and SDN lies in creating an open, standardized platform on which developers can innovate quickly.

So, we set out to create Floodlight, pouring in much of what we learned from talking to top researchers and leading hardware and software vendors, and we are inviting everyone in the OpenFlow community to participate in its development.  With your help, we’ll help OpenFlow realize its potential.

Ready to go?  Download the code, read the documentation, and join the  mailing list.