 Okay. Very good. Thanks, folks, very much for stopping by. So my name's Phil Robb, and I'm going to talk about Open Daylight. Open Daylight's been around for just about a year now. We launched 13 months ago on April 8th of 2013. Again, my name's Phil Robb, and I work for the Linux Foundation, and I spend all of my day job actually just facilitating the community around Open Daylight. So I want to talk a little bit about what Open Daylight is, give some current statistics on where the project is, talk about the first release that we had, the current release called Hydrogen. Also talk about what's coming in new as far as getting everybody up to date on what the project is about to go launch into for development activities. Some more focus areas on our second release, which is called Helium, and then just end with where you can find out more about the project. So what is Open Daylight? Open Daylight is really about a community for building an open source SDN platform. We wanted to really look at this in three different prongs, one being code, good code to use, as well as acceptance, get broad industry participation. As we saw SDN beginning to form as a concept and a technology, there were a lot of disparate different methods of doing it, and so much of this is just core platform that needs to be done for everybody to build solutions on. So we wanted to build an open source project to get there and then have a true open source community similar to OpenStack as far as anybody who has an innovative idea and has the time and energy and effort and passion to come bring a project and come bring their effort, then they were very welcome. And so that's what we really formed. Specifically, we're building an SDN platform, and it's important that we talk about the evolvability of that platform. There are lots of different meanings and terms for software-defined networking these days. We don't really know today what it's going to look like in five years and two years. We're very much in a greenfield area here as we try to build these networks where you have a separation of the data plane and the control plane, and you now have all of this information available to that control plane where it can see the full breadth of the network, what it all looks like, as well as managing both the overlay and the underlay of virtual environments. So we want to create these abstractions for the northbound, for applications that are using Open Daylight. And in our context for Open Daylight, OpenStack is an application. It sits north of us. It's going to call upon an SDN controller, such as Open Daylight, to manipulate both virtual and physical network underneath. So when Open Daylight talks about applications, OpenStack is one of the most important ones that we have. We want to be able to actually intermediate what those requests are from those northbound applications and then be able to manage those down into a southbound set of devices, be them virtual or physical, within the network. So have a common abstraction for the northbound applications above the controller and then a common method or a way of actually manipulating different kinds of devices southbound of us. This also includes applications to manage things. The folks from Open Daylight gave a talk earlier today talking about having an application that can implement flavors of OpenStack. And that's something that we're going to be working on throughout this year and probably in the next year. I'll talk a little bit more about that later. Just a summary from our first year. Again, for a project that's been around for only 13 months, 1.17 million lines of code is an awful lot. So obviously we had some large contributions to really kick this project off. We started with about 30 contributors in April of last year and we've got about 181 active contributors now. Very surprising to me and so it is of note, we actually won Best of Interop a month ago. We're the first open-source project to ever win Best of Interop. And so I'm not quite sure how that works, to be honest. Open source is about the technology. It's not about a product. And very much Best of Interop I had always thought was more about polished products that go into users' hands. But I mean, if you look at it from an impact to the industry standpoint, I think that's really why we won. Again, I would not advocate that everybody go off and take this code and go put it in your production environment and want to rely on it on a day-to-day basis. Again, we're a young project. We've got a ways to go. But it was quite fulfilling to actually be, again, the winner of Interop as a very significant technology for the networking industry. We won a variety of other awards. We've doubled in size. For those that missed the announcement earlier, HP actually moved their membership today from Silver to Platinum because it's now going to be a key piece of their future work as well. Again, we had our first release, which is code named Hydrogen on February 3rd. We have our second release Helium planned for September 29th. There are three products right now that I know of that are based on Open Daylight, as well as many that are actually on the drawing boards for 2014 and 2015. So for Hydrogen, this is the standard diagram, and if you want to stop by the booth, we can send you off with one of these. But the important thing here is that you've got the applications that are writing on top, a common set of northbound RESTful APIs. This technology is Java-based, and we also use OSGI for creating bundles for the project. So you can either interface with it straight through Java if you're running on the same machine, or you can go through the RESTful APIs if you're off-box. A set of networking service functions, as well as room for additional services, all sitting on top of a service abstraction layer. And it's that service abstraction layer that allows for a common set of northbound APIs to talk to a disparate set of southbound protocols depending on the devices that you're talking to. Those southbound protocols, OBSDB, Metconf, and so forth are also part of the project. And then that dotted line is really where we end our scope. So things that are underneath that dotted line, like actual physical devices or virtual devices like OBS are outside of the scope of our project. So this is what Hydrogen looks like, and those are the commons that are part of it. We're just now, so today is actually in the lifecycle management for Helium for our second release. Really, okay. All right, that's fine. All right, I guess I'll do this now. So today is actually the day that new projects are supposed to be identifying themselves as wanting to be part of the Helium release. So we've been going as a project, we've been going through a series of creation reviews for different project proposals. I wanted to talk about the projects that have come thus far. So these are all projects that have been introduced since Hydrogen actually went out the door. So these are new projects that will be part of future versions of Open Daylight, but we're not actually part of Hydrogen. First one being Deluxe. This is a project for a much better augmented user experience and user interface for Open Daylight based on AngularJS, or AngularJS, rather. The group policy plug-in is for identifying policies for different type of end nodes, and that is going to match up with the group-based policy that's inside of OpenStack. So the naming and its purpose are very closely aligned and intertwined with the needs of OpenStack as well. Open Daylight Toolkit was a project that was brought forward to basically leverage Maven archetypes to make it much, much easier for developers to create applications and begin to test new applications sitting on top of Open Daylight. So if you've got an idea for an application, looking at the Toolkit project may very well help you jumpstart what that application looks like, so I would suggest you go there. Documentation in general, again, is a new project. It typically is one of the last things to get off the ground right behind a lot of code. So having a project that both works specifically on creating good solid documentation as well as integrating tools to have documentation generated as part of the build process is really the idea behind this project. Dynamic resource reservations, so being able to set out flows and identify resources and paths based on different criteria is what the Dynamic Resource Reservation Project is about. Negotiable data path models is really an implication of TTPs. If you're familiar with the Open Networking Foundation work that's being done in the forwarding abstractions working group, one of the things they've been doing is trying to figure out how best to manage the variability of functionality that can exist in switches, particularly with OpenFlow 1.3, and so this is a way of managing that and trying to trim down the combinatorics of what you could do with the extensions and the options for OpenFlow 1.3 and instead have this as a protocol and so that's another project that's been introduced. Packet Cable PCMM is another project that's been a proposal that's been brought forward and has been accepted into incubation. Specifically this came from the folks at Cable Labs. They want to be able to manage CMTS type of cable modem devices as just another network element in their environment so they added a southbound protocol so that they could manage it from the controller. The ODL ROOT parent is an internal project that's really geared towards improving how the different projects inside of Open Daylight manage their own objects and the dependencies across the different projects. As we've grown and we've had these new projects come forward, being able to manage the dependencies and continually roll forward in a continuous build environment is what we're going through is growing pains and so this is a project brought forth by members of that community to make it so that it's much easier as we're continuing to do this. The OpFlex protocol that's been submitted to IETF for a standard for implementing and managing application policies down to networking element devices has been proposed and is introduced. The ODL SDNI project is about using, it's about creating an east-west protocol set for doing controller federation. They want to base this off of BGP as a base protocol to start with but as we look at both doing clustering using Infinispan, using other technologies as well or federation where BGP is a natural first choice to begin east-west protocols, the ODL SDNI project is geared towards doing that. A southbound plugin for the OpenContrail platform so actually integrating and allowing manipulation of OpenContrail through Open Daylight has been brought forward by the folks at Juniper. This last page are actually projects that have been proposed but they have not yet gone through their creation review. We have one final creation review set that will be occurring this Thursday and I felt remiss if I weren't going to at least include a brief description on what these look like again because they're quite reasonably going to be part of the Helium release as well and accept it on Thursday but these are not yet approved. One is around authorization, authentication and accountability for both machines and users on the net and that's the AAA service. The L2 switch is really somewhat of a refactoring taking the core functionality for L2 functions and actually turning it into its own project separate from the controller and making it a little more abstracted so that it can be basically augmented and leveraged more than just the way it is now embedded inside the controller. Service function chaining will be the first to actually build an effort to put service function chaining features and API sets inside of Open Daylight and then secure network bootstrapping infrastructure as it describes basically leveraging certificates on hardware and understanding a set of boot priorities and secure boot devices that can be brought up inside of that controller environment with key networking elements as well secure from boot. So those are the items that are there. Key themes for us are really around stability, scalability and performance, improved ease of use for new users as well as developers and you can see that with like the documentation as well as the toolkit projects that we have. Again improved processes for both continuous build as well as release and getting more work done with real users. We've started a whole series of proof of concepts as well as the user group. Ways to get started and you can take a look at these slides after the presentation's over. The Wiki and the mailing lists are really the best ways to get involved. There's a YouTube channel that has a lot of great intro videos if you want to learn more about Open Daylight and then of course we're on Twitter as well as Facebook and again come to the opendaylight.org site. With that, thank you very much for your attention.