Announcing Floodlight v1.0

After months of collaboration and hard work, I am pleased to announce the release of Floodlight v1.0. Floodlight v1.0 has full support for OpenFlow 1.0 and 1.3 along with experimental support for OpenFlow 1.1, 1.2, and 1.4. Here are the highlights of what Floodlight v1.0 has to offer and how you can get your hands on it:

At it’s core is the OpenFlowJ-Loxigen (or OpenFlowJ-Loxi for short) generated Java library, which among many powerful things abstracts the OpenFlow version behind a common API. Loxigen works by parsing OpenFlow concepts defined as structures in a set of input files. It then generates a set of Java, Python, and C libraries for use in OpenFlow applications. The Loxigen-generated libraries abstract away low-level details and provide a far more pleasant and high-level programming experience for developers. It is straightforward to define each OpenFlow version in Loxigen’s input files, and each OpenFlow version is exposed through a common API, which results in few if not zero application code changes when adding OpenFlow versions. In other words, Loxigen provides a fairly future-proof API for the many OpenFlow versions to come. The Loxigen project is open source and can be found on GitHub here.

Floodlight of course uses the Java library generated by Loxigen, also known as OpenFlowJ-Loxi. Although OpenFlowJ-Loxi is the new heart of the new Floodlight controller, there have been many higher-level changes necessary to accommodate the new library as well as to fix some known bugs and improve the overall performance and capabilities of the Floodlight controller. Many will go unnoticed; however, some will have immediate impact on how your modules interact with the controller core.

For instance, the Floodlight v0.90 and v0.91 (old master) Controller class was, among many things, responsible for managing switches. This responsibility has been relocated from the Controller class to a new class called the OFSwitchManager. It is exposed to modules as a service, the IOFSwitchService. Instead of accessing switches using the IFloodlightProviderService, developers should instead depend on and obtain a reference to the IOFSwitchService.

Furthermore, the Static Flow Pusher and REST API in general has undergone an extensive renovation to enable full OpenFlow 1.3 support. More information on the Static Flow Pusher and its REST API syntax can be found here. Please note any syntax changes from prior Floodlight versions, and be certain to use the correct syntax for your OpenFlow version.

One of the key features of Floodlight v1.0 is its full support for OpenFlow 1.0 and 1.3, complete with an easy-to-use, version-agnostic API. Each OpenFlow version has a factory that can build all types and messages as they are defined for that version of OpenFlow. This allows for a very much improved way to create OpenFlow Messages, Matches, Actions, FlowMods, etc. The creation of many OpenFlow objects has been greatly simplified using builders, all accessible from a common OpenFlow factory interface. All objects produced from builders are immutable, which allows for safer code and makes your applications easier to debug.

To best demonstrate the extent to which constructing and working with OpenFlow concepts such as FlowMods has been improved in Floodlight v1.0, consider the following before and after example.

/* Pre-v1.0 -- the old way to compose an OFFlowMod */
OFFlowMod flow = new OFFlowMod(); // no builder pattern; not immutable
OFMatch match = new OFMatch();
ArrayList<OFAction> actions = new ArrayList<OFAction>();
OFActionOutput outputAction = new OFActionOutput();
match.setInputPort((short) 1); // not type-safe; many OpenFlow concepts are represented as shorts
match.setWildcards(Wildcards.FULL.matchOn(Flag.IN_PORT).matchOn(Flag.DL_TYPE)); // wildcarding necessary
outputAction.setPort((short) 2); // raw types used; casting required
outputAction.setLength((short) OFActionOutput.MINIMUM_LENGTH);
flow.setLengthU(OFFlowMod.MINIMUM_LENGTH + outputAction.getLengthU()); // length must be set correctly
/* Floodlight v1.0 -- the new and improved way to compose an OFFlowMod */
ArrayList<OFAction> actions = new ArrayList<OFAction>();
actions.add(myFactory.actions().buildOutput() // builder pattern used throughout
  .setPort(OFPort.of(1)) // raw types replaced with objects for type-checking and readability
  .build()); // list of immutable OFAction objects
OFFlowAdd flow = myFactory.buildFlowAdd()
    .setExact(MatchField.IN_PORT, OFPort.of(1)) // type-checked matching
    .setExact(MatchField.ETH_TYPE, EthType.IPv4))
    .build()) // immutable Match object
  .build(); // immutable OFFlowMod; no lengths to set; no wildcards to set

Some of the concepts above will be discussed further below, but the major items to note are the use of the builder design pattern for ease-of-use and the production of immutable objects, the use of objects instead of raw types to enforce type-safe coding and to produce more readable code, built-in wildcarding, and finally there is no need to deal with message lengths.

All switches that connect to Floodlight contain a factory for the version of OpenFlow the switch speaks. There can be multiple switches, all speaking different versions of OpenFlow, where the controller handles the low-level protocol differences behind the scenes. From the perspective of modules and application developers, the switch is simply exposed as an IOFSwitch, which has the function getOFFactory() to return the OpenFlowJ-Loxi factory appropriate for the OpenFlow version the switch is speaking. Once you have the correct factory, you can create OpenFlow types and concepts through the common API OpenFlowJ-Loxi exposes.

As such, you do not need to switch APIs when composing your FlowMods and other types. Let’s say you wish to build a FlowMod and send it to a switch. Each switch known to the OFSwitchManager has a reference to an OpenFlow factory of the same version negotiated in the initial handshake between the switch and the controller. Simply reference the factory from your switch, create the builder, build the FlowMod, and write it to the switch. The same API is exposed for the construction of all OpenFlow objects, regardless of the OpenFlow version. You will however need to know what you are allowed to do for each OpenFlow version; otherwise, if you for example tell an OpenFlow 1.0 switch to perform some action such as add a Group, which is not supported for it’s OpenFlow version, the OpenFlowJ-Loxi library will kindly inform you with an UnsupportedOperationException.

There are some other subtle changes introduced, for the better. For example, many common types such as switch datapath IDs, OpenFlow ports, and IP and MAC addresses are defined by the OpenFlowJ-Loxi library through the DatapathId, OFPort, IPv4Address/IPv6Address, and MacAddress, respectively. You are encouraged to explore org.projectfloodlight.openflow.types, where you will find a wide variety of common types that are now conveniently defined in a single location. Like the objects produced from builders above, all types are immutable.

For more information on how to use the new APIs exposed in Floodlight v1.0, please refer to the OpenFlowJ-Loxi documentation and examples.

There are many more minor details, which can be found in the release notes. I have been grateful to have the support of many Floodlight developers, and together we have worked to provide the highest quality release within a reasonable time frame. I would especially like to thank the following individuals and beta testers for their code contributions, debugging efforts, and assistance throughout the development and release process:

Rui Cardoso
Hung-Wei Chiu
Rich Lane
Qingxiang Lin
Sanjivini Naikar
Jason Paraga
Naveen Sampath
Rob Sherwood
Sebastian Szwaczyk
KC Wang
Andreas Wundsam

Based on further community feedback, there will be minor releases to address any issues found or enhancements anyone would like to contribute. The mailing list has seen quite an uptick in activity over the last few months (minus the holiday season =) ), and I look forward to seeing all the novel and innovative ways people find to use Floodlight v1.0!

If at any time you have a question or concern, please reach out to us. We rely on our fellow developers to make the most effective improvements and find any bugs. Thank you all for the support and I hope you find your work with Floodlight v1.0 fun and productive!

Floodlight v1.0 can be found on GitHub at:
Any updates leading up to a minor release after v1.0 will be placed in master at:
And finally all “bleeding edge” updates will be in my repository’s master branch at:

If you need an older version of Floodlight for any reason, they can still be found on GitHub.
Floodlight v0.91 (old master) can be found at:
Floodlight v0.90 can be found at:

The download sites and will be updated as soon as possible and in the near future.

Lastly, I’ll leave you with a short list of to-dos for upcoming minor releases. These are items I would have liked to have incorporated into v1.0 but did not fit within the release timeframe. If anyone is interested in exploring these avenues of development and contribution, please feel free to ask and I can provide you with the details. All other suggestions are welcome as well!

  • Modify the Static Flow Pusher to check flow validity before inserting flows into storage. This will allow a detailed, root-cause error message to be sent back to the user via the REST API.
  • Add handshake handlers for OpenFlow 1.1, 1.2, and 1.4. OpenFlow 1.1, 1.2, and 1.4 concepts and types are supported by the controller; however, the initial handshakes have not been completed yet.
  • Find and fix a very rare bug (only seen twice in 6 months) that causes an OpenFlow 1.0 factory to be used with an OpenFlow 1.3 switch upon initial handshake. This will cause an exception to be thrown. I have noticed it when the switch is under high load and has many unmatched packets about to be sent as OFPacketIns after the handshake completes.
  • Modify Loxigen to force OFMessage and all classes that extend it to not use the XID field in their equals() functions. This bug prevents comparing the content of an OFMessage without explicitly comparing each field of the OFMessage minus the XID (and the content varies per OpenFlow version and per OFMessage type). This bug is presently impacting the OFMessageDamper; the details of this issue are included here.
  • We do not have a VM yet that contains Floodlight v1.0 and an updated OVS. You should download Floodlight directly from GitHub.
  • Create a “compatibility layer” that allows all pre-v1.0 custom modules work seamlessly within Floodlight v1.0.
Happy coding!

Ryan Izard
ECE Department, Clemson University
Big Switch Networks

Demo: OpenFlow enabled network card

Contributed by Eli Karpilovski, Senior Manager, Cloud @ Mellanox (

I’m excited to showcase the results of a demo we put together leveraging the Floodlight controller and our new OpenFlow-enabled NIC. This particular demo enables extraction of network information to detect and protect against security threats in real-time for a more resilient and cost-effective mobile network.

The demo uses the following technologies:

Click to Enlarge

  • Radware Application Delivery and Attack Mitigation Security
  • Mellanox 10G and 40G embedded virtual switch (eSwitch) NIC
  • Floodlight SDN controller

Combining these technologies illustrates an innovative ability to extract network and application information that can be translated and leveraged to a scalable solution for detection of various security threats, in real-time.

Continue reading »

SDN Use Case: Multipath TCP at Caltech and CERN

“Everything is getting better with Moore’s Law, but some things are getting better faster than others.”

— Kenneth Church, “The Mobility Gap”


Almost everyone has heard of Moore’s law, which states that CPU processing power goes up by about 100x per decade.  Fewer of us have heard of Kryder’s Law, ie the “Moore’s Law of storage” – it says that we can expect a 1000x increase in disk capacity per decade.  And even fewer have heard of Nielsen’s Law for networking – which only claims a 256x increase of bandwidth capacity in the workplace over the same period.


In short: bandwidth rates aren’t keeping up – in a large part due to limitations of the speed of light. It is this gap in improvement in storage and bandwidth density that Mr Church coined the “mobility gap”. How big is the gap?  Roughly 4X – 18x over each decade. Which doesn’t seem that bad until you also consider the “digital universe” problem which says that AMOUNT of global data is 44x time what is was in 2009 by 2020.

Continue reading »

Floodlight Use Case: Software-Defined Storage

Our friends at Coraid used Floodlight to demo a Software-defined-storage use case at this year’s VMWorld 2012 in San Francisco.

Alok Rishi, Coraid’s Chief Software Architect, showed how one could use Floodlight’s v0.85 REST APIs, controlled programmatically via the Ethercloud orchestration stack, to dynamically create isolated data flow paths end-to-end:  through the Coraid storage targets, through the Coraid initiator, then onto the VM.

We are especially excited about this demo because:

* the integration combines both virtual switches (OVS + Xen) and physical switches (openflow-enabled Arista)

* EtherCloud is controlling Floodlight entirely through REST APIs.

* the entire demo was set up in just a few days

* the demo also showcased the Avior Floodlight GUI application written by Jason Parraga

This is just one example of creating value by combining SDN controller + cloud orchestration stacks + storage +  OpenFlow enabled switches. We would love to hear more examples and ideas from you.

A block diagaram of the setup can be seen here:


Here is Alok performing the demo at VMWworld:


From left: Mike Cohen (Big Switch), Alok Rishi (Chief Architect, Coraid), Paul Lappas (Big Switch), Doug Dooley (VP Product @ Coraid)



Floodlight Update

My colleague Mike Cohen has done an amazing job growing and evangelizing Floodlight since  launch earlier this year. I wanted to relay some of the notable facts are:

  • Over 6,000 downloads since January 2012
  • A Google search on “floodlight” returns this project as the first natural result
  • Downloaded by IBM, Arista Networks, Brocade, Dell, Fujitsu, HP, Intel, Juniper Networks, Citrix and Microsoft.

To continue Floodlight’s meteoric growth, we will be spending the next few months focusing on tools and processes to promote quality and collaboration:

Testing Framework

The goal here is to target 100% automated test coverage of the project by releasing a good test execution framework and set of automated tests.  This is so that when you add a change you can be sure that your new code didn’t break existing functionality, and fix any problems before you submit a pull request to get your changes in. Of course this means that you as a developer will also need to check in a test with your changes.

Better transparency

In what features are proposed, features being worked on, and the scope of the next few releases (roadmap). As someone with a background in delivering large scale projects on time and budget, I know how important it is to have visibility into what’s working and what’s coming. This is so that potential developers know where they are needed most

Coding style and standards

Obviously important that we can set up guidelines for implementation so that the code base can grow in a way that is well understood and sane.

And much more to come!

Doubling-down on OpenFlow

I’m incredibly happy to announce that I’ve joined to help lead our efforts around open source, including Floodlight, the world’s only apache-licensed SDN controller, and Indigo, an OpenFlow agent for physical switches.

First, a little bit about me:

In 2006 I co-founded and ran engineering and operations for GoGrid ( , one of the world’s first cloud computing service providers. After growing GoGrid to span two continents and service over 10,000 enterprise users using only open-source tools (and what was at the time the second largest Xen deployment next to Amazon EC2) I decided to refocus my efforts on where I saw most of the adoption of cloud would be happening:  private deployments inside of enterprises providing automated self-service to internal development and IT groups.  I ended up helping Piston Cloud ( – who was building a distribution of OpenStack – bring their product to market, until my friend Kyle Forster @ Big Switch told me that he was looking for someone to help grow out their open source efforts that include Floodlight and Indigo.

Now, I had been keeping my eye on OpenFlow and SDN since 2007 when Martin Casado pitched us his idea to connect virtual hosts via dynamically provisioned (what were then GRE) tunnels when we were trying to figure out how to scale the GoGrid network (we decided the technology was too immature). So my first reaction to Kyle was “why does Big Switch need an open source strategy?”. After all it’s no secret that it’s very difficult to make money selling open source technology. Not saying it’s impossible – obviously companies like Redhat have found the secret – but unless your market is gigantic and product is extremely easy to deploy and support, it becomes very difficult to turn a profit. And as a startup in the incredibly competitive enterprise infrastructure market and competing with a giant like Cisco, you could say I was “cautiously intrigued” by the idea.

I wanted to be sure that Big Switch was serious about doing what it takes to truly create a vibrant open source community – the most important attribute of which is a diverse set of contributors who are not dominated by one company or influenced by commercial interests.

After spending a few weeks with the team, a few things became obvious:

— Big Switch’s commercial products have an incredibly compelling value proposition (hint: it’s all about the Apps)
— Floodlight represents the “core” of the commercial product (that is still in Beta), and
— with Floodlight, we have the opportunity to define the de facto standard for controller APIs
— we have assembled the best engineering team for SDN in the world

I look forward to diving into this in much more detail as we become more public about our plans, but I can say that I’m incredibly excited about the opportunity that we have in front of us, and what this means for developers and users of SDN technologies as we disrupt the world of network infrastructure.

You can reach me anytime at or email to the floodlight-developer group.