 Okay, very good. Welcome folks. My name is Phil Robb, I'm a senior director with the Open Daylight project. I'm just going to give you a little bit of an overview of Open Daylight, kind of talk about where we are, explain a little bit about the architecture, what's coming up new, and I'm going to start off by talking about why should you care. You know, what is it that Open Daylight actually brings to OpenStack and the OpenStack community. So first off, you know, the network has certainly changed over the last 35 years or so since TCP imp was initially made. We've got an explosion of virtual machines, an explosion of endpoints, an explosion of devices on the network, and that's just moving at an exponential rate at this point with things like the Internet of Things and with cloud computing and virtualization that we have here. So it doesn't really matter, though, because if you can't properly connect all of these endpoints, it doesn't matter how quickly you can spin up a compute node, how quickly you can spin up a storage node. If you can't actually connect them intelligently, then you've got a problem, right? And so OpenSDN, open source SDN controllers like Open Daylight are made to solve that problem, right? Made to give you that flexibility and that agility that you haven't had. So what we're trying to do is really bring the industry together. This is not an easy problem to solve. Again, we've had this network grow over the last 40 years or so. It's quite unwieldy. Getting everybody together in a room working as a community to fix the problem, right, to create a platform that everybody can use. That's kind of like the first step, right? And out of that, out of the work that we do, we end up with de facto standards so that we can move forward quickly and actually being able to create networks that can connect all of our virtual machines and virtual storage that we're putting out there on the net, right? So that's really half of the battle, right? Is creating a community just like the OpenStack community, getting everybody trying to work together, solving their own problems but leveraging each other's work. That's how we get someplace much faster than us doing it all alone. So bringing that together. So from an industry standpoint, we've been doing pretty well. We continue to grow. We continue to bring a lot of vendors and now a lot of users also into our community to actually build this SDN platform. This slide actually shows all of the different organizations that are currently putting products out based on Open Daylight, okay? So you haven't seen a show this slide before, right? I mean, we launched the project in April of 2013. We spent, you know, a couple of years getting a solid base, very similar to OpenStack right in the beginning when we had the A and the B and the C release. You know, when Diablo came out, that's when people started talking about trying to put stuff up for real, right? This is where we are, right? And we got real users, real customers that are actually out there now also joining our community, helping us to develop this. We're currently working on our fourth release. We've had three releases thus far. And this is just, again, to kind of show the momentum both in projects as well as contributors that we've got into the project. So I showed this slide in Vancouver. It was just fresh off of a deck that AT&T had done at the NFV World Congress in May. And it kind of shows how they're using Open Daylight and OpenStack, right? As well as a couple of other controllers in their domain to architecture, right? So that's one. Since then, Telstra, with the help of Marantis, is also deploying Open Daylight to help manage their network, right? With a cross-connect fabric, all right? Behind that, we've got Tencent, who's now, again, working with WeChat. They're actually using PSAP, in particular, and a custom-made MD-SAL application. We'll talk a little bit about the MD-SAL here in a minute. But they've got, they've now got Open Daylight as part of their solution, or part of their infrastructure. And they're asking all of their partners to also use it, again, because it's becoming ubiquitous across the industry. And then this is an organization in Canada where they're actually building a green cloud, right? Again, kind of managing the Internet of Things types of devices. And they've got a layer into a network also using OpenStack, collecting all of that data. And they're using another one of our projects called Time Series Data Repository, or TSDR, to collect the statistics off of those Internet of Things sensors and devices. And then there's China Mobile, and they're actually deploying using service function chaining, right? So starting to use NFV in their actual applications. And so they've started to talk about what they're doing. So that's also good. So point behind those slides are just to say, you know, we've got, we've got users, and we've got real deployments now. We're quite proud of that. And we've got more and more users coming into our community. We did a survey. And these are the four major use cases coming out of SDN, right? Centralized network monitoring and management orchestration. That's not got so much to do with OpenStack. But proactive network management and traffic engineering, depending on what you're doing and what those VMs are doing, that's actually, it relates. Network function virtualization is all about connecting some kind of controller to manager network, as well as being able to virtually spin up different loads and then chain those, chain the packets through those different VMs. And then obviously cloud networking, classic network virtualization is also another major use case. So out of the study, those are the four things that came out. And it just shows that, you know, it's more and more we've got a direct coupling between what we need to do in the cloud and how we actually manage our physical infrastructure underneath that. So the users that you saw up there are also something that we've been actively working on over the last six months is to bring out more and more users as advisory groups. For us and our community, it's been quite interesting. Over the last three months, we've now begun an active dialogue between the technical steering committee and the advisory group. They're helping to arbitrate as we come up with different questions that we really want to ask about what's the priority, how should we handle different situations when it comes to how we're architecting our product and our project. Again, a lot of what we're doing is bleeding edge. So we're ahead of standards. We're ahead of a lot of normal activity. And so having a user base that we can directly ask and get feedback on for, you know, our most recent was we have a problem with the way netconf is implemented. And it's a bug. And it's kind of like a bug in the implementation of the standard. And do we enforce the standard and not let things mount? Or do we allow it? You know, the users want us to allow it, right? But it's good to hear. It's good to hear what the users are actually telling us. So we know what their real world situations are. And if you notice out of this advisory group, again, we started kind of with telcos in academia. Now we're moving into financial services as folks that are interested in what we're doing. And that's just where we're going. I want to talk a little bit about the architecture now. So we've shown a version of this slide for the last, again, however many two years worth of OpenStack summits that we've been to. And the things, the green boxes there, they just continue to become more numerous, right? These are applications or services that we have inside of the controller, as well as a variety of southbound protocols, right? I mean, the interesting thing about Open Daylight is that it's not just an open flow SDN controller. Some people use this just with NetConf to manage their networks. And that's an option, right? You can use it strictly for open flow and managing just true, pure SDN type of applications as well. That's quite doable. But if you want to use PSEP and BGP to manage your routes for your legacy hardware, you can do that as well. But as we continue to show this diagram, people continue to go, gee, that sure looks complex, right? Again, the important point here is to realize that you don't have to use all of that. You get to pick and choose what pieces you want to use, right? When we talk about this, we've always described it as layers, right? You've got applications and an API, and then you've got these services or apps inside. We've always talked about this service abstraction layer and then a series of protocols. I want to kind of dig into that a little bit for folks today to shine a little more light on that. In the beginning, we actually had two different versions of a service abstraction layer. The first one was pretty much hard-coded. And it was pretty error prone. It was difficult for developers to actually use. So we created a model-driven one. And so the way that model-driven service abstraction layer works is you've got applications inside the controller, right? And then you kind of move through that service abstraction layer to talk from an application or service down through the abstraction layer down to a protocol. So we always described it in these layers. But in reality, that's not really what's going on. And so we thought it might be better to explain it in a different way. When we talk about a model-driven service abstraction layer, it's really just a model-driven core, right? Here you get to describe what your process or your application is going to do or serve for any other application. And you actually define that through a Yang model, okay? So Yang is just a tree-structured language, you know, DOM type format, where you can describe what that looks like. And we have Yang tools that will generate an API based on the model that you provide that then allows you to connect up the services that you want to give or to provide to any other application in Open Daylight. And the interesting thing is it doesn't matter if you're an application or if you're a protocol, the process is the same, right? You define that Yang model, what it looks like, you know, to expose your services, APIs are generated. And then from that, you actually have applications that can tie into that API, right, and expose the service, be it a protocol plug-in or be it an application. So what it really means is that you can be a protocol plug-in or an application, you're really on the same level, it's not really layered. What you really have is this core that provides a Yang-based representation that allows the different services to talk to one another, okay? And in that core, you have a shared data structure or a shared data store that is, again, represented as a Yang, or as a Yang model, and you have messaging, right? You have RPCs, you have notifications, and so forth that allow the applications to talk to one another. And again, in this scenario, it doesn't matter if you're implementing a protocol on the southbound or if you're implementing a service within the project, okay? So and then we also provide clustering of all of that so that it's highly available and scalable. So given that, you can have consumers that are outside of Open Daylight talking through either NetConf or ResConf, right? Talking to different providers inside of the controller, or you can have different applications actually providing and consuming data across inside. And then from the southbound protocol standpoint, those are providers, right? Activities are happening on the network that goes through a provider, through the protocol plug-in or through the NetConf client, and then that can be serviced up into consumers that be at applications outside of Open Daylight. So when you look at the way we actually implement that when you're talking about open flow, right? So you've got applications, you've got configuration that's coming in through those applications through through NetConf and ResConf, and that modifies the configuration entry inside of this core, inside of this Yang model, right? That kicks off a notification to the forwarding rules manager, which then notifies the open flow plug-in, modifies the open flow plug-in, then actually talks to the switch. To change that configuration when the switch comes back with its status, it updates the actual operational side of the tree. And you can see we have a configuration side and we have an operational side. Configuration is reflecting what applications are telling the controller to do. Operational data storage is actually reflecting what's going on in the network. So that's the data that's actually coming from the network elements, right, through the southbound protocol. You've got a topology manager that, again, gets updated from the change in the operational store from the open flow inventory, and that manages the open flow topology. So those are how the pieces fit together, right? So instead of thinking this is a layer, right, it's actually a variety of microservices that are unable to talk to each other through a common data store and a set of notifications. So another example, this one with OVSDB and NetVirt, right? And you can see, you know, it's up to the applications and it's up to the protocols as to what they want to store in that common data store and how they want to do the notifications, right? That's actually what you're defining in your Yang model, right? So here we have Rescoff, we have OpenStack through our northbound API service. It talks to the rest of the OVSDB and network virtualization layer for that project. There's a topology based on OVSDB that pumps OVSDB changes through to the open flow switch. Similarly also through open flow, and then the open flow inventory is actually maintained there as well, right, with those services tied to each other. Here's another example, but this one it's not necessarily SDN, right? So this is the Internet of Things. We've had a group come in and provide some southbound protocols that are unique to the Internet of Things data management, right? There's a whole set of protocols that these sensor devices use to talk to one another as well as to data manager collectors, right, for collecting and monitoring that sensor data, right? So implementing one of those databases inside of the controller is what this project is doing. A variety of protocols specific to IoT, be it HTTP, MQTTP and Co-App, are all protocols that talk to these devices and they're maintaining in their data store, right? And ultimately they can notify each other, right, through the federation of all that data that's being collected in the IDM database. Group-based policy is yet another example, okay? Same type of thing, RESTConf is the interface through the applications, a variety of different storage elements to get the policy that's stored in the common data store, the neutron group-based policy mapping, the actual endpoint database, the OVSDB topology and the open-flow inventory are also again still there within this framework and obviously we're controlling open-flow switches through group-based policy and that's how those services link together, right, and talk to one another. So I just kind of wanted to show that because what we've got, now we've got about 55 projects and they're starting to build upon each other, right? We still have some projects that are duplicative, in particular when you talk about abstraction we seem to have a variety of domain-specific languages to manage the abstraction that a controller would want to present to OpenStack or to any other application, right? Having to actually program layer 2 flows from an application is probably too low level, that's kind of like assembly, right? We need a higher level language, right, so that we can actually talk, but what that language is is under debate, right? We haven't done this before, there's a variety of ideas about how you might want to do that. So we have five different abstraction languages right now that different folks are working on. We expect them to consolidate, some will probably just kind of fade away, others will probably consolidate. Group-based policy currently seems to be a rendering engine of choice for other abstractions that are acting as domain-specific languages specifically for what you're trying to do, and so that's kind of where that sits, but that's just the kind of evolution that's happening within Open Daylight. So again our next release is Beryllium, it's coming up on February 4th. For all of the existing projects most of them are working on better scaling, better performance, just the typical things you would expect similar to OpenStack. Improving the support in particular for Neutron, for APIs, continuing to get to feature parity, we will be there with Beryllium as well as better integration with advanced features like group-based policy, service function chaining, virtual private network and so forth, and then we have some new projects. We have too many to call out individually, but I did want to talk about this one a little bit. This project actually was born out of our last design summit where, which happened at the end of July, and it was really particularly in the context of network function virtualization, we came to the recognition that under some situations we actually may want the controller to ask the the virtual, the cloud orchestrator to spin up some VMs, right? We might be able to detect a problem or detect saturation of a network or some other situation in a network where we actually want the controller to ask OpenStack to spin up VMs and then actually have them connect, right? Create a virtual network connection through Open Daylight for those and so Armory is a project that's doing exactly that, creating an API set for Open Daylight that in turn will then call OpenStack to actually bring up VMs, specific types of VMs and so forth. So it's the SDN controller asking the cloud orchestrator to perform services as opposed to the cloud orchestrator asking the SDN controller to perform. So it's going to be, it's a two-way street with the Armory project. Other projects that are new in the beryllium timeframe, Net IDE is an interesting project, somebody's, they were actually trying to create in essence a shim or a common set of APIs so that one controller can call another. So in particular they're working with Ryu, they're working with I believe Nox, Pox and Floodlight to be able to allow applications written for those controllers to work with Open Daylight and vice versa. So again they're trying to create an abstraction at the REST conf layer or the HTTP REST conf layer or REST API layer rather for different controllers. Nemo is one of those, again, another abstraction language that's a domain specific language in particularly focused towards telco. OpenFlow extensions for the support of circuit switching, well that doesn't really need more of an explanation than just that title. But there are extensions inside of OpenFlow for allowing manipulation of optical networks and so this project is actually implementing those. Fabric as a service is another, it's also doing an abstraction but it's doing it at a different layer, it's actually abstracting the elements within Open Daylight so that they can be more easily programmed against from those different northbound abstractions. Messaging for transport, we're adding instead of just REST conf, we're also adding support for northbound bindings for AMQP as well as XMPP. And then controller shield is interesting as well. It's looking at both the northbound application interface as well as east-west federation interfaces as well as the southbound interface of Open Daylight which are the three different entry points or attack targets from a security standpoint and actually looking to harden those as well as provide additional statistics up to applications based on the triggers that are found there. Then finally we have Sentinel which is basically adding on to the time series data repository with doing additional logging information. We have an expanded user interface project called Next and then also a group implementing the OpenFlow config. With that I'm actually out of time so thank you very very much for your attention and if you have any additional questions please just head to the booth and we'll be happy to go into detail on any of this for you. Alright, thank you very much.