 This kind of just outlines what our timeline looks like. Again we launched in April of 2013 that first release we code named Hydrogen. It came out in February of this year, then we started working on Helium the second release. Helium just released at the beginning of October, okay so it's about a month old. So we're just now still building out our release plan for Lithium, our next release. The dates for Lithium and Beryllium are tentative because obviously we haven't finalized those. So I have to put that caveat out there but it's looking like it's going to fall somewhere in the middle of next year for Lithium, probably June. But again over the next two weeks actually the technical steering committee will finalize that plan. And for us that's actually kind of nice because it's going to map up really well with the work that's going on inside of OpenStack for Kilo and we have strong aspirations that I'll get to with that collaborative work. So talking about the Helium release in particular. So this is the architectural diagram, again if you kind of map out the application space on top, the services space in the middle, and then the blue boxes down along the bottom are the southbound protocols that we support. So Hydrogen as well as Helium have specifically an OpenStack service that interfaces to the ML2 mechanism driver for Neutron and underneath that we have a variety of virtualization technologies that can be chosen, one or the other. In addition to that for Helium we spent significant time just building out the stability, the scalability and the performance of the core controller. As you can imagine with the first release it was really about getting everybody together, getting the code base together and showing that we can put something out with Hydrogen. Second release Helium was really about continuing to allow new features to come in but also hardening what we had to begin with and that will be a trend as our project continues to mature. Again not so different from OpenStack. From a new feature standpoint we've added some security aspects so if you look along the top bar there there's AAA which is authentication authorization and accounting and that's managing the access to the northbound interface or to the API interface to the controller. In addition we've added say a secure network booting infrastructure so certificate-based authentication of the network elements that are actually connecting to the controller and this is done at boot so we've got security both from the bottom end with the network devices as well as the application and the user level. Next we added table type patterns as support for OpenFlow 1.3. OpenFlow 1.3 is a continued version of the OpenFlow protocol that's really allowed for some additional capabilities inside of switches to be exploited by the protocol. One of the problems with the early versions of OpenFlow was it only had one table lookup so you couldn't really make decisions on multiple different criteria for the packets that were coming in so the ability to have different table lookups and kind of cascade them and put them in a pipeline was something that 1.3 introduced but then that introduced a level of complexity and flexibility that actually made the implementation of it difficult so table type patterns is just a way of mapping you know what type of pipeline you can build and support inside your switches and then that can match up to the controller so that those types of flows from the controller to the switch can be mapped so it's a nice extension to the controller to be able to again leverage OpenFlow 1.3 as best it possibly can. In addition we've also had a couple of other services one being group-based policy that was added as well as service function chaining. Those are both additional northbound API and service capabilities some of which map nicely to activities that are going on inside of OpenStack in particular group-based policy and we hear a lot about network function virtualization and the leverage of OpenStack as well as Open Daylight to actually do that for the carrier in the telecommunications market and service function chaining is a key piece of that. It's really about being able to map different functions and have the traffic be engineered so that it flows through each one of those virtual machines with the different functions in a serial manner. So in addition so we have a controller federation feature that's also been added to the helium release and that actually leverages the BGP protocol so that different instances of Open Daylight controllers can share topology information across one another. We also have a couple of new protocols that were added. One is actually a plug-in to OpenContrail and that was contributed by Juniper so you can actually manage OpenContrail controlled networks from Open Daylight. And then in addition the folks from cable labs came and contributed a packet cable multimedia protocol which allows them basically to not only manage their networks and their network connectivity with Open Daylight but also some level of management of the actual set top boxes or the endpoint devices that sit inside of the cable network. So helium specific improvements or I'm sorry OpenStack specific improvements that we did in helium. We really wanted to come up and have better feature compatibility and parity with what's available inside of Neutron. So the addition of security groups DVR distributed or virtual routing load balance as a service as well as our responder were things that were added to the OVSDB integration. Again managing OpenV switch through both OpenFlow and the OVSDB protocol are one of the aspects or the characteristics of Open Daylight and what it can manage. Again in addition there's a group-based policy activity going on inside of OpenStack. We built out the initial framework to be able to be compatible with that group-based policy invocation with the group-based policy activity that's going on inside of Open Daylight. Again it's interesting to recognize that OpenStack is a very important northbound application for the Open Daylight SDN controller but certainly the an SDN controller can and will be used in a variety of situations where a cloud virtualization layer may not necessarily be on top. So aspirations for lithium and kilo. We had a session yesterday specifically talking about how we can continue to collaborate. One area for us is we want to really expand both the breadth and the depth of our continuous integration testing that we're doing. We are a third party CI site for OpenStack and have been since well for the past eight or ten months or so. But we really want to continue to build out the use cases for our continuous integration with the with the OpenStack community. Additional clustering and scalability testing are also very important to us as well as further integration of our OBS DB project. Virtual tenant networking which is another virtualization technology inside of Open Daylight. The group-based policy and the service function chaining. Getting all of those better tightly integrated into into Neutron are areas that we'll be focusing on hopefully with members of the OpenStack community as as kilo and lithium development progress. Additionally from a new feature standpoint right now we do support controller restarts from Neutron but there are places where it just needs work better state maintain or state maintenance of the status of the controller when those restarts occur is one area. Doing full bi-directional rest calls is another area for us that we want to focus on as well as improving those capabilities of the distributed virtual routing, load balances of service, group-based policy and service function chaining. And so with that those are the areas where we really want to focus. I know we've got lots of folks inside of the Open Daylight community that want to be working on these pieces. We're continuing to really solicit participation and collaboration from the OpenStack community as well. So if any of those activities and management of your virtual and physical networks underneath Neutron and Underneath OpenStack are something that's interesting to you or your organization, I strongly recommend and encourage you to come join these activities that we'll be working on through this next cycle. Ways to get a hold of the Open Daylight project, again www.OpenDaylight.org, wiki.OpenDaylight.org is where all the development activity occurs and then on Twitter as well for up-to-date activities. And with that I thank you very much for your attention.