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.

OpenFlowHub

OpenFlowHub.org launched in January 2012 as a registry to promote OpenFlow projects from all over the world. Some of these projects were contributed by Big Switch, some – like Flowscale and Routeflow – were not. We have extremely strong heritage around OpenFlow here: our founder Guido Appenzeller was one of the inventors along with our CTO, Rob Sherwood. And so it was always important that we support the OpenFlow protocol – hence the name OpenFlowHub.

Floodlight quickly became the leading open SDN controller with 6,000 downloads by August of 2012. If you go onto the Floodlight mailing list today, you’ll see individuals from all around the world answering questions directly on the list. People who we’ve never met before. Most time, much more quickly than our own staff. It’s incredible. We have strangers sending in questions and other strangers helping them. The ability for this global community to support users is incredibly powerful.

And Floodlight has grown to more than just a research project. We’ve compiled a great list of how companies are using the project’s to assist with their SDN product development and get to market faster.

List of orgs using Floodlight and Indigo

Project Floodlight

Over time, two things became clear. The first is that it’s incredibly hard to build a community around projects in which you are not an expert. We had people asking questions and using the projects but, we couldn’t control the resources. And so it was hard for us to help.

Second and perhaps more importantly:  Big Switch expanded our open source offerings significantly. With the launch of our next generation Indigo Agent and LoxiGen, we now have projects that cover the entire 3-tier architecture. We’ve got projects at the application tier: virtual switch, openstack plugin, ACL apps, etc, and of course Floodlight, the leading open source SDN controller.

100% Open Source SDN Stack

The Indigo Agent rounds out the offering: no other project in the world offers 100% open source solutions to build SDN – all the way down to the data plane. Big Switch now has the complete SDN stack – and so we wanted to re-position the site to reflect that change in focus. It’s about focusing on build the largest open source SDN community in the world.

Licensing and Partners

I want to talk a bit about licensing for the Indigo Agent. Floodlight is and remains licensed under the permissive Apache version 2 license.

Now, distribution has always been a key goal of our open source strategy. That’s why we are open sourcing our code. And when we started thinking about what we wanted to achieve with Indigo, it became clear that we also had to think about our partners, and potential users. We searched for a license that would help us achieve the following goals:

• enable partners to create openflow enabled devices so customers can choose from a wide range of options.
• reduce fragmentation – ensure the core engine of Indigo remains open – which is where compatibility with openflow controllers happens.

Uncontrolled customization leads to incompatible implementations – and that is not good of for the end user. The key consideration was the preservation of the core OpenFlow implementation code. And so we chose a license that requires customization to our own files to be open sourced, but permissive enough to allow partners to extend the platform and keep their extensions closed – if they write the code in a way that doesn’t modify our own files. That license is the EPLv1 and you can read more about it here.

Now, some partners want to do more complex things with Indigo, and integrate with hardware SDKs in a way that violate the EPL. For those partners, we also offer a commercial license to OEMs or ODMs. We’ll give them a flexible license that they can use. In addition, if you are a company with an existing relationship with Broadcom, who wishes to license our Broadcom forwarding driver, we’ll give that to you, as well – we’ll do a 3-way NDA with Broadcom. We’ve done that for a number of partners already.

Conclusion

We are really excited about the future of Project Floodlight. We are just getting started. As always, please send in your comments, feedback and advice to paul@bigswitch.com.

Thank you!

The post Introducing Project Floodlight appeared first on Project Floodlight.

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.

With these low-latency NICs, customers can deploy an embedded virtual switch (eSwitch) to run VM traffic with bare-metal performance, provide hardened security and QoS, all managed with Floodlight OpenFlow APIs. The hardware-based security and isolation features in the Mellanox cards can enable wider adoption of multi-tenant clouds while maintaining SLAs. And, utilizing SR-IOV to bypass the Hypervisor achieves higher VM utilization per node when virtualizing network functions in private cloud deployments.

The post Demo: OpenFlow enabled network card appeared first on Project Floodlight.

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.

It somewhat reminds me of the 
early days of operating systems — it seems everyone is writing one, and
 there is a lot of difference between them.  I think of it like the
 difference between the rather trivial operating system that a computer 
science undergrad writes in her senior-level operating systems class vs. a 
fully functioning commercially supported operating system like Mac OSX or 
even a popular, well-tested open source operating system like Linux. Is
 “while(true){do()};” an operating system?

 There are fundamental differences between the capabilities, features, and
 even architecture that will separate the toy projects from the controllers built for production deployment- the useful special-purpose controllers from the 
oddities.

I expect there to be many experimental controllers, especially those that cater to a particular programming language or environment. As software developers get their heads around the idea of programming network applications, an existing frame of reference provides an important bridge whenever programmers are learning new technology. Over the long term, some winners will emerge.

Also, there are increasingly many special-purpose controllers.  Much like a general purpose OS like Linux is quite different, a 
virtualization specific OS like VMWare’s ESX, (which is different still
 from embedded OS controllers) seems to also come in a wide variety
 of specializations like general purpose (e.g., Floodlight),
virtualization specific (e.g., FlowVisor), and even controllers for embedded devices for mobile phones.

Only time and mind share will tell. Of course, I have a preference beginning with the Floodlight controller which enables developers to use a system that provides a mix of
”simple to learn” and “robust enough for deployment” criteria. Floodlight is packaged 
in a single JAR file. Using the REST API, programmers can write applications 
in any language they choose. (Java and Python seemed to be popular with the
Floodlight community.) 

The various controller present features are as varied as: “presents raw OpenFlow 
messages to the application writer” and “presents pre-computes possible (but 
not mandated) broadcast domains on top of mixed OpenFlow and non-OpenFlow
 topologies”.

I work on Floodlight, and the features that I’m most proud 
of are the modularity, the host discovery, the mixed OpenFlow/non-OpenFlow
 topology and forwarding support. When the time is right, there is a clean
 upgrade path for porting applications to our commercial product: the Big
 Switch Controller (with all of its enterprise bells and whistles). I’ve yet 
to see any of the other open source controllers that offer comparable
features, but I’m definitely appreciating the excitement.

The race is on for what 
will become the SDN controller equivalent of Linux vs. the SDN controller
 equivalent of Minix (remember that!?). May the best software stack
 win!  Because somewhere in our minds, when we’re innovating and solving problems, we’re at some level all just a 
bunch of kids having fun.

About the Author:  Rob Sherwood is a key architect of OpenFlow 1.0, Floodlight, and FlowVisor. In his spare time he is the Chief Technical Officer, Controller Technologies at Big Switch Networks.

The post Nah Mate, That Ain’t A Controller… THIS is a Controller appeared first on Project Floodlight.

– 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.

Researchers are particularly hard-hit by this growing problem. As instruments get more and more sophisticated, the amount of raw data that is capture is increasing all the time. At the same time, more and more scientists around the world want to get their hands on it for their own research, meaning that huge amounts of raw data are being shipped around the world.

So we have MORE data, LESS ability to move it around, and MORE demand to analyze it.

One of the best ways to increase bandwidth levels is to improve the utilization rates of existing circuits. And that is exactly what researchers at Caltech and CERN did. At this years’ Supercomputing Conference (SC12) exhibition in Salt Lake City from November 10-16,  they demonstrated by using a per-flow multipath switching fabric based on Floodlight.

The team, lead by Dr Michael Bredel of Caltech and CERN, implemented various Floodlight modules that form a basic per-flow multipath application, and extended the given topology management to calculate link-disjunct paths between source and destination nodes. The corresponding OpenFlow forwarding entries are pushed to the related switches automatically, whenever a new flow appears at the ingress of the OpenFlow network. Moreover, new flows are allocated to possible paths in a round-robin manner.

To demonstrate this, they created a world wide meshed layer-2 OpenFlow overlay network by connecting Pronto OpenFlow switches in Geneva, Amsterdam, Chicago, and Salt Lake City via 10 Gbps links on top of a standard R&E network environment. The direct connectivity of the OpenFlow equipment has been achieved by VLANs, and they used multipath TCP (MPTCP) to split a TCP datastream to multiple TCP sub-streams and send the data on multiple paths from source to destination.

They proved it is possible to improve the datarate, and push it beyond the limits of a single path.  Another great example of SDN improving ROI.

Links:

http://supercomputing.caltech.edu/pictures.html

http://supercomputing.caltech.edu/sc12_OF_Mptcp.html

http://www.caltech.edu/content/high-energy-physicists-smash-records-network-data-transfer

The post SDN Use Case: Multipath TCP at Caltech and CERN appeared first on Project Floodlight.

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.

In fact, this argument isn’t even new:  fear, uncertainty and doubt. Rackspace was under similar fire before, during – and to some degree, after – their huge continuing investment to move OpenStack into a Foundation that today enjoys over 400 active developers from over 180 companies who have contributed over 500,000 lines of code.  Rackspace eventually moved the project to a foundation after it was clear that the community was broad enough and strong enough to support such a move.  In fact, Rackspace never needed to make money on the OpenStack code:  they were primarily a service provider who had a vision for hybrid cloud, who saw the value in an ecosystem who could out with R&D, and supply their partners (and customers) with software that they could interoperate with.

Subversion is another example of a project that started as single-vendor open-source (founded in 2000 by CollabNet) and has seen incredible success over the past decade.

At Big Switch Networks, we’ve heard these arguments before, but we’ve been quite successful at convincing our multitude of partners and users to join us.  Here’s why:

• There will be an Open SDN controller standard to compete with proprietary controller solutions from VMware and Cisco.  That  controller will be the Linux of networking, the MySQL to their Oracle. The Apache web server to the cadre of Web server from the mid 1990s. Big Switch Networks is as committed as our users and partners are to keep the controller open.

• Our choice of Apache2 for a license is very different from MySQL or Java. Apache2 means we want to help partners. You don’t like how we run the project? Fork it!  Already we have heard of many, many companies who have built products on Floodlight. If we wanted to control or limit that adoption, we would’ve picked a less permissive license like the GPL.

• Our entire platform is built upon industry standards and, where they do not exist, we have published our own work. We do not have proprietary tunneling, overlay, or communication protocols.  We have demonstrated this commitment repeatedly with the contribution of our open core, Floodlight, to the to open source community and the publication of common APIs across both our commercial and open source controller.

• Big Switch Networks is the only vendor in the industry with a truly platform-independent approach and a commitment to an open architecture. We’ll continue to deliver on that commitment going forward.  We represent the industry’s most open and standards based SDN and OpenFlow implementation and advocate of an open architecture – period.

It’s very easy to say “this is all good and well, but if Big Switch gets a 1B offer from Cisco, they won’t turn it down” and the result will be that the open ecosystem will be shut down.

But this statement fails to consider that the ecosystem, the project, and the vision for Open SDN are larger than any one company.  If Big Switch Networks were to disappear tomorrow, there would still be over 10,000 organizations who have downloaded the project,  dozens of individuals who have contributed to the project (who are not Big Switch employees) as well as of hundreds of developers who participate on the mailing lists. Furthermore, the project is Apache2 licensed and can be forked at any time by any organization.

Big Switch does not want to dominate this project, because that would mean that we are proprietary, which is precisely the opposite of our vision for Open SDN. Consider:

• If there was an open API standard already, we would have adopted it instead of defining one
• If there were already dozens of OpenFlow switches on the market, we would have integrated with them instead of helping switch vendors build them with our Indigo and LOXI projects
• We integrate with OVS instead of writing our own vSwitch because it’s already standard and in wide use
• We support OpenFlow because it is sanctioned by the ONF (and hey, our CEO along with several Big Switch architects invented it! We’re committed to open networking.)

As a partner or a user, the real question you have to ask yourself is not “what happens if Big Switch gets acquired” but instead “do I believe that an open standards, open API, and open source” approach is the future of networking.

What’s the alternative? Are there other competitors that have exhibited a more open architecture?  Is there some non-profit industry group that has infinite resources to build and support commercial-grade deployments with another open source controller?  In the real world, we’re are the only vendor committed to providing an open architecture and open core controller for the growing SDN industry. Period.

If you believe strongly in this vision, then how about joining up and helping us transform networking with Open SDN?

The post Open Source and Floodlight: The Biggest Opportunity for SDN appeared first on Project Floodlight.

The post Announcing Floodlight v0.90 appeared first on Project Floodlight.

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 paul@bigswitch.com 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.

Webinar Slides

Webinar Video + Audio

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:

 http://groups.google.com/a/openflowhub.org/group/indigo-announce/subscribe
 http://groups.google.com/a/openflowhub.org/group/indigo-dev/subscribe

The post Preview of Indigo v2.0 and LOXI appeared first on Project Floodlight.

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)

1

The post Floodlight Use Case: Software-Defined Storage appeared first on Project Floodlight.

• 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!

The post Floodlight Update appeared first on Project Floodlight.

First, a little bit about me:

In 2006 I co-founded and ran engineering and operations for GoGrid (www.gogrid.com) , 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 (www.pistoncloud.com) – 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 paul.lappas@bigswitch.com or email to the floodlight-developer group.

The post Doubling-down on OpenFlow appeared first on Project Floodlight.