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

Interop 2012 OpenFlow Roundup

_MG_7695 At last year’s Interop Las Vegas, OpenFlow was the surprise sensation of the show. In fact, Network World went so far to argue that it could have been called the OpenFlow Show. We had high expectations for this year, and we were not disappointed. OpenFlow was everywhere at the show, whether as generally available products, demos or prototypes. It received (again) the “Best of Interop Award” and it was the elephant in the room during Cisco’s keynote. At the same time, the conversation around OpenFlow has changed. If last year was around hype and speculation, this year was around products, use cases and in a few cases customer success stories. Here is our list of OpenFlow related exhibits at Interop. If we are missing anything let us know in the comments.

Arista – At the Arista booth, there was a joint demo together with Big Switch Networks to showcase Network Virtualization using OpenFlow. Several of Arista’s 7050 Switches were used to create virtual networks leveraging both the switch’s hardware capabilities as well as Hypervisor Switch based overlay networks. Arista’s EOS architecture is very well suited for Software Defined Networking and it is great to see another OpenFlow enabled switch becoming available. The network virtualization functionality was provided by the Enterprise version of the Big Switch Controller. It provides redundant controller nodes for high-availability and management is done via an industry standard CLI or Web UI. To the right Dan Talayco and Jeff Townsend from Big Switch.

Continue reading »

Understanding OpenFlow: Packet-In is a Page Fault

One of the most fundamental and often controversial features of the OpenFlow protocol is the “packet-in”.  Recall from the specification that the OpenFlow controller pushes packet forwarding rules down to an OpenFlow device.  Each rule is of the form “if a packet’s header matches pattern X then apply policy list Y”.  When a packet arrives that matches an existing rule, the corresponding policy is applied, e.g., what interface to forward out, what QoS queue to apply, etc.  However, if a packet does not match any of the existing rules, OpenFlow’s default policy is to send a copy of that packet up to the controller.  This “packet sent to the controller” message is called, in OpenFlow-parlance, a “packet-in”.

Now, if you work with large networks (either operate them or sell to people who do), the concept of _intentionally_ sending packets to controller by default—and thus across the control plane—frankly probably has you horrified.  Data packets going on the control plane is a denial of service (DoS) waiting to happen and you’ve probably spent a good chunk of your career either debugging the resulting problems (“Why is my router’s CPU at 100%?  Aargh!”) or trying to ensure that this DoS can’t happen in the first place (“Sure IP multicast (or unsampled netflow, IPv6 options parsing, etc.) would be useful, but I disable it because I worry that it could cause instabilities”).  Yes, equipment manufacturers spend a lot of time trying to ensure that data packets get punted up to the control plane only when absolutely necessary (e.g., for routing protocol updates), but the harsh reality is that even hardened “carrier-grade” production equipment still occasionally falls victim to a control-plane DoS[1].  This is not because vendors are incompetent but rather because it’s inherently a very complex engineering game of wack-a-mole.  Each new feature might impose a different requirement on data-to-control plane interactions, and the sum of all features on the box have to result in a unified set of rules that decide which data packets can go to the control plane and how they are rate limited.  Being too conservative with these data-to-control-plane rules and rate-limits risks DoS on the control plane: routing processes become starved, CLIs hang, and networks can destabilize.   But on the other side, being too aggressive—that is blocking or rate limiting too much—can break features or have a negative impact on performance.

If the bad news is that the data-to-control-plane problem is well-known and hard, then the good news is that all of the same tools that vendors already apply to this problem are also available to OpenFlow controllers.  That is: an OpenFlow controller can block traffic, install rate limiters, or even change the default policy for an unmatched packet to drop it on the ground.  Depending on the applications loaded and the target network deployment, the OpenFlow controller will apply different drop rules, rate limits, and default policies.  For example, a Tier-1 service provider network will likely choose to only send routing updates (likely rate limited) to the controller and drop all unmatched traffic, where a security-sensitive enterprise network might choose to send as much unmatched traffic as possible to the controller for auditing and monitoring purposes.  The bottom line is that using OpenFlow does not fundamentally change this problem: all of the same dangers, solutions, and trade-offs exist.

Once you accept that packet-in—when used properly—is a safe and even necessary component to any functioning network, the real fun can start because packet-in is the networking equivalent of a virtual memory page fault.   While they add a degree of overhead that must be managed, Packet-in’s, like page faults, also enable all sorts of new functionality.   They make it possible to offer applications a clean programming interface, create hooks for sophisticated resource management, and even enable advanced capabilities like virtualization.

Obviously, one could talk about this analogy at length but I wanted to present it to the community to generate discussion and get people to step a little out of their comfort zone.  Does it work for you – feel free to chime in on the comments…

[1] From which, unfortunately, I can personally attest: some of my past network research work accidentally exposed holes in the vendor’s control-plane rate limiting policy, much to the unhappy surprise of more than one operator.


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.

Why OpenFlow Hub?

For many of us who have gotten involved with OpenFlow over the last few years, the starting point was and We read the spec, downloaded NOX and one of the OpenFlow software switches, played with the learning switch example and then started experimenting from there. It was fun.

As corporate interest around OpenFlow has grown and the “state of the art” is increasingly pushed forward by commercial products rather than the academic community, a lot of the leading edge work is now hidden from view. Many of the people who have been involved in OFH have been, admittedly, a part of this trend – a number of us work for various companies involved in OpenFlow.

That is part of why a group of us got together to start this site. The goal was to create a soap box for people leading interesting OpenFlow-related projects. We believe that even in a landscape of increasingly commercial activity, there is plenty of room (or even a necessity) for open source utilities, reference implementations, teaching aids, test tools, experimental designs and even community alternatives to commercial products. *All* OpenFlow projects are welcome here.

The initial projects you see were originally written by Big Switch Networks and Stanford, with additional projects and authors coming over the next few months. If you have a project and you’re looking for a place to host-and-boast, we hope that The Hub can be a part of your plans. We offer a set of customizable tier-1 tools to help you best manage your project: Confluence (wiki), Jira (bugtracker), and vBulletin (forum). We also have a (small) team here to help you to get the word out about your project.

We are comitted to keep OpenFlow Hub separate from any commercial efforts. OpenFlow Hub will host any OpenFlow project, even if it goes against anyones commercial strategy. You pick what license you like, you retain all ownership of your project and you are free to take it somewhere else if you ever want to.

If you have a project you’d like to host on the Hub, just drop us a note at and we’ll set it up.

Guido, David, Kyle & Alex for the Hub Team

Welcome To The Pre-Launch Party!

Welcome to The Hub! If you’re reading this, you’re one of a few folks involved in the “pre-launch” version of The Hub. You’ll probably find a few missing images, a few broken links and a few “lorem ipsum” placeholders around the edges. Welcome to pre-launch!

Thank you for taking the time to post. If you have questions, comments and feedback (preferably the kind of feedback we can take action on in the hectic 1-2 weeks leading up to a launch), drop a note to Kyle and David. In the meantime, please feel free to add pages and comments on the projects that are up and soon-to-be-up.

Thank you!