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.setDataLayerType(Ethernet.TYPE_IPv4); match.setWildcards(Wildcards.FULL.matchOn(Flag.IN_PORT).matchOn(Flag.DL_TYPE)); // wildcarding necessary outputAction.setType(OFActionType.OUTPUT); outputAction.setPort((short) 2); // raw types used; casting required outputAction.setLength((short) OFActionOutput.MINIMUM_LENGTH); actions(outputAction); flow.setBufferId(-1); flow.setActions(actions); flow.setMatch(match); flow.setLengthU(OFFlowMod.MINIMUM_LENGTH + outputAction.getLengthU()); // length must be set correctly sw.write(flow);
/* 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() .setMatch(myfactory. buildMatch() .setExact(MatchField.IN_PORT, OFPort.of(1)) // type-checked matching .setExact(MatchField.ETH_TYPE, EthType.IPv4)) .build()) // immutable Match object .setActions(actions) .setOutPort(OFPort.of(2)) .setBufferId(OFBufferId.NO_ BUFFER) .build(); // immutable OFFlowMod; no lengths to set; no wildcards to set sw.write(flow);
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.
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:
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:
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.
Contributed by Paul Lappas, Head of Open Source @ Big Switch Networks.
I’m incredibly happy to announce some really exciting things that are happening in open source at Big Switch Networks. Today we announced the launch of a commercial version of Indigo Agent, which is a fully deployable thin switching software platform called Switch Light, and a revamped open source site: ProjectFloodlight.org. In this posting I wanted to explain how we got here and why we are making these changes.
Contributed by Rob Sherwood – CTO of Controller Technologies at Big Switch Networks.
I’m hearing more and more about SDN “controllers” these days.
Tech Execs at big networking companies are talking about delivering controllers in coming years. And I still see interesting projects emerging from academic institutions. Even Lua students can now experiment with OpenFlow controllers. In general, this is a good thing and I’m happy to see it.
In a recent post on SDNCentral titled “Open Source: The Biggest Risk to SDN”, the author attempts to define the various types of open source business models, including how value is created for users and partners within an open source ecosystem. He described some risks facing partners and users when they are considering adopting code from “single-vendor” projects, specifically calling out the Floodlight and Indigo projects, which are supported in large part by Big Switch. And then he posits a scenario wherein Big Switch is acquired by a competitor with a poor open source track record (think: golden gate bridge, and switches and routers).
The author takes the position that single-vendor poses a risk to SDN adoption as a whole by concluding that users and partners should be very wary of using Floodlight & Indigo code because it is very likely that Cisco may very well acquire Big Switch and thus close the project down.
While I’m a reader of SDNCentral, I believe that the author misses the point entirely. Continue reading
We are pleased to announce the release of Floodlight 0.90! The 0.90 release consists of new controller REST APIs, new applications, bug fixes, a new test framework and contribution guideline, and a completely revamped documentation wiki.
- Integration Test Framework & Suite. Big Switch is open sourcing a test framework called “Floodlight-Test” to allow developers to easily develop and run integration tests. From release 0.90 and on, all developer contributions are required to have accompanied unit tests, integration tests, and documentation.
- Revamped Documentation. A new docs site with a new structure for more efficient access to user and developer oriented information. New tutorials/guides are provided to assist in every stage of the usage and development process. Specific instructions are also given in the wiki to describe a contribution process and a jira-based feature/bug tracking system.
The Big Switch team has been working overtime to develop a new version of the popular Indigo project. Indigo is an OpenFlow firmware agent for physical switches, and info on the current version can be found on http://indigo.openflowhub.org.
In version 2, we extend the framework to make it easy to support new versions of OpenFlow, as well as:
- a HAL abstraction layer to make it easy to integrate with the forwarding and port management interfaces of physical- or virtual- switches
- a configuration abstraction layer to support running OpenFlow in a “hybrid” mode on your switch
- LOXI – a marshalling/un-marshalling engine that generates OpenFlow libraries in multiple languages. Currently it generates C, but Java and Python are coming soon.
Indigo 2 will be officially released into open source later this year under the Apache version 2.0 license. Until then, we are working hard to shore up documentation and update the web site. If you wish to see the code sooner than that (like now), please send your github ID to firstname.lastname@example.org and we’ll provide you with early access.
Want to learn more? Following these links to download a recent deep-dive performed by Dan Talayco and Rob Sherwood over the web.
To stay up to date on the launch, be sure to subscribe to the indigo-announce and indigo-dev mailing lists by following these links:
I am proud to announce Avior, an open source project developed by the Marist College/IBM Joint Study OpenFlow research team. Avior was designed to fill a void in the realm of floodlight administration while propelling the forward development of open source Floodlight applications. The application runs independently of the controller and communicates with the controller using the default restAPI.
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.
Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!