OpenDaylight is an open source software project focused on advancing Software-Defined Networking (SDN). The Developer Spotlight blog series profiles the people who are contributing to the project.
Colin Dixon is a computer systems researcher at IBM Research's Austin Lab. His research interests are broadly in systems, spanning networks, distributed systems, operating systems and security with an emphasis on building real, secure, reliable and efficient computer systems. He's on Twitter at @colin_dixon.
How did you get involved with OpenDaylight? What is your background?
I've been pretty intensely involved with OpenDaylight since the beginning. I'm a researcher at IBM working on SDN and before OpenDaylight, I did a lot of work with, and contributed to, the Floodlight OpenFlow controller. As a result, I heavily contributed to IBM's first OpenFlow controller, which was based on Floodlight, and when IBM was spinning up OpenDaylight, I became IBM's unofficial OpenDaylight technical expert.
I got a lot more intensely involved during the beginning of the consortium since I was one of a small number of people who was familiar with the code for both of the controller projects that were originally part of OpenDaylight.
My background is pretty heavily steeped in SDN. Since joining IBM Research I've been working in a data center networking group focusing on SDN. Before that, I got my PhD from the University of Washington in distributed systems and networking and my thesis focused on making networks programmable whether they were enterprise networks or networks of devices in houses. The part about programming houses was called HomeOS and is still ongoing at Microsoft Research.
What projects are you working on for OpenDaylight? Any new developments to share?
Most of my attention goes to the controller project. I try to improve the core functionality as best I can including helping out with performance improvements, improving overall code quality and helping improve some of the build system. I've also been trying to help out with the OpenFlow plugin and OpenFlow protocol library projects since they play a core role in the controller.
While not officially a project, along with David Erickson I put together the (in)famous Dixon-Erickson proposal that helped to resolve the impasse around how to proceed with two different controllers. The plan still stands as a roadmap indicating what features any OpenDaylight controller should have in the long run and suggestions about where code for those features should come from.
In terms of new developments, I'm working on lots of small things that I'm hoping to get into OpenDaylight in the near future. I'm working with Curt Beckmann of Brocade to incorporate some of the Negotiable Datapath Models (NDM) work that we did as part of the ONF's Forwarding Abstractions Working group which should allow for the controller and switches to agree on a set of features. (Curt wrote up a good blog post on this a while ago, but using the term Pre-Defined Switch Profile or PDSP instead of NDM.) I've also been working on implementing an application to allow the controller to act as a single Ethernet switch including handling broadcast traffic.
People have different definitions for SDN depending on how they're using the network. What's your definition of SDN?
I'm tempted to cop out here and say "I can't really define SDN, but I know it when I see it," but I'll take a stab at defining what I feel the core of SDN is.
In my mind, software-defined networking really has three parts:
- First is the separation of of the control plane and data plane which is as close to a "standard" definition of SDN as currently exists.
- Second, as part of that, you need to have open definitions of the APIs that the control plane can expect from data plane and vice versa. OpenFlow is one example of such an API.
- Third is the logical centralization of the control plane so that network application developers and network administrators can think of the network holistically rather than as a piecemeal collection of devices.
Once you have these three parts, you can start to really change the way we think about networks from having a limited set of proprietary knobs on a bunch of different devices to having general purpose network operating systems like the OpenDaylight controller.
From your perspective, what are the major benefits of making OpenDaylight an open source project?
Much like the Linux operating system and Apache web server, OpenDaylight offers a way for the whole industry and community to collaborate on shared infrastructure rather than having many parallel efforts reproducing the same functionality. It is precisely the fact that OpenDaylight is an open source project and not owned by any one company that makes this possible.
What advice would you give to someone just getting started in OpenDaylight?
Grab the code and get it to do something first.
A good place to start is getting the installation guide which also walks through getting the simple forwarding application to work. There's a few moving parts, but the documentation there is pretty good and if you need any help you should jump on #OpenDaylight channel on the freenode server and there's almost always people willing to help out there.
From there, we have a curated and documented list of small, but very useful tasks that need work along with mentors that are willing to help out. Other than that, hop on the mailing lists and chime in.
Lastly, again, don't forget the IRC channel. Really. It's the best way to get fast feedback.
When and how do you get your best coding done? At night listening to music? In the morning with a cup of coffee?
I really need a good 2–4 hours of uninterrupted time to "page in" the relevant information into my brain and get coding effectively. The result is that I usually get my best coding done someplace far from meetings, phones, instant messaging and e-mail. Planes are great for this. The last two patches I pushed up to OpenDaylight were things I wrote and prepared on a flight from Baltimore to Austin.
No comments:
Post a Comment