 All right, hi everybody. Thanks for coming here just before lunch. That's great. Today I'm going to talk to you about Open Vertex, which is a network virtualization platform that allows you to specify your own topology and addressing. And basically it introduces the concept of a virtual software-defined network. This is work that I and Mark did. Mark unfortunately can't be here. And he's also the guy who did all the open stack related stuff. So I'll try and do my best with them. So today I'm going to go through some motivation why we want to do this, the architecture of, sorry about that, then go through the architecture and some features. And I'll talk to you, talk to you what probably interests you the most, our OVX Neutron plugin and our current and our plan deployment. And then if we have self some time, I'll do a demo at the end. So this probably comes with no surprise to you guys. I mean network virtualization is basically the killer app for SDN. And simply because it allows you to deploy a multi-tenant network on your same physical infrastructure. And it does this with security and simplifies the management of your virtual networks and of your physical infrastructure. All right. So why did we bother to build Open Vertex when there are all these other network virtualization platforms that exist today? The reason is simple. There are no network virtualization platforms out there currently that allow you to program the virtual network they produce. So that means that they use some flavor of SDN to give you virtual networks, but then they take SDN away from you. And I think that's not cool. We should be able to program our virtual networks. That's exactly what OVX does. So let me go through some use cases to motivate what OVX can do. So first, imagine a scalable cloud service. Where what we define as a service is something with a well-defined programmatic API. It's scalable. And it's more importantly implemented as a network of VMs. So if you wanted to scale the service, it's not sufficient to just scale your number of VMs. Because the more VMs you have, the more traffic you want to attract. And you want to cloud up your network. So you need to scale the compute and the networking simultaneously. And that's exactly what OVX does. So for the rest of this talk, for the next couple of slides, I'm going to use this image to depict a scalable cloud service. So in current carrier central offices, there are a bunch of services. And due to legacy limitations, legacy protocol limitations, a subscriber's traffic has to go through every single point in every single service to determine whether the subscriber has subscribed to the service and determine whether the service has to be applied to this traffic. It's kind of a waste of performance. And it could also lead to a privacy problem. So how do we solve this? So we claim that we can solve this by composing services together, which are composing services together, which are supported by virtual networks. And how do you do this? Well, imagine each of your services implemented as a virtual network. You take each service, and then you wire them together to implement the chain that you want for your subscriber. And then all the traffic goes through only the services that the subscriber is subscribed to and nothing more, making it easier to manage and more efficient. It's kind of cool. So imagine now you are the CEO of some Fortune 500 company, and you talk to one of your CEO friends, and he tells you about this thing called the cloud. And since you believe everything your CEO friends tell you, you want it immediately. Now, the problem is that if you go back to your staff and tell them we have to rebuild the servers that we've built in-house, and we have to rebuild it on this cloud infrastructure, you probably have a mutiny on your hands. So how do you do this? How do you transition to the cloud? Well, you take your cloud infrastructure network, and what you really want to do is spawn a virtual network that looks exactly the same as the network you had in-house. And that's exactly what OVX does. All right, so let's move on to some architecture of OVX. So OVX sits in between the open flow network and the network operating systems, and it speaks open flow north and south, so north to the controllers, and south to the data plan. OVX has three main features that enable to do its job. The first one is topology virtualization. Next is address virtualization, and finally, control function virtualization. And I'll talk about these three in the next slides. So for topology virtualization, what OVX does is OVX allows you to spawn any topology you want. And how does it do that? It does that by decoupling the virtual network completely from the physical network. So OVX discovers the topology just like any other SDN controller, and eventually here it'll have discovered the entire physical network. And it's assumed that we have two virtual networks configured in OVX, and they're connected to some network operating system. These network operating systems start sending LLDPs to discover a network, and what OVX does is resolve them and send them back to the network operating system. This allows us to create any virtual network we want. And all OVX has to do now is maintain a mapping between the virtual elements to the physical elements. So another key feature of OVX is address virtualization. So basically, OVX supports overlapping addressing schemes. And so the way it achieves this is by exposing only a virtual topology to the tenant network operating system. And when his VM starts talking, the first hop switch inserts a tag and a packet header. Therefore, thereby isolating the tenant's traffic and identifying which tenant is responsible for this traffic. And the cool thing about this is that nothing has to change. Your network operating system is unmodified, and your tenant and your VMs remain unmodified. They have no idea that they're operating on a virtual network. So OVX can spawn a virtual network, virtual topology, any topology you want, and provide any addressing you want. Now, how do we allow you to program that virtual network? Well, each of these virtual networks behaves just like an open flow network. So that means that you can stick your favorite controller on top of it, whether it's open daylight, floodlight, whatever you want, and program your network. And you can do fancy things like fancy routing, some traffic engineering, whatever you want. Kind of cool. All right, so OVX is a network hypervisor which introduces the concept of a virtual software-defined network. It has a bunch of other features, like the ability to start, stop, add, delete networks and network elements dynamically. And it also has the ability to create resilient giant switches and resilient virtual links. I'll show you these features in a demo. So let's check out what we do in OpenStack. So I think all of you guys know this diagram. It wasn't all that wobbly, maybe. But all you guys know this diagram really well. Well, we think it's far too complicated. There are far too many bridges. There are far too many moving parts, and it's just a nightmare to maintain. So what we've done is we've replaced all of this with a single OVX integration bridge, which connects to OVX. And then you implement the policy of your network in these network operating systems on top of OVX. So we support the complete Neutron API. And what we currently do is we only, in the context of OpenStack, we only spawn giant switch typologies and connect it to a default controller. Adding custom controllers won't be a big deal. It's very easy. But we haven't had the need to do that so far. On the other hand, support for custom typology will be harder, simply because we need to extend the Neutron API with a typology API. And also, network embedding is an NP-hard problem. So it'll be harder. And the cool thing about this work is that we leverage NOVA to spawn our controller, our default controller VMs. And that's kind of cool, because it's kind of like a nice bootstrapping method. So this is the kind of the plugin architecture. Nothing fundamentally has changed. We have the Neutron API. And the Neutron plugin speaks to an OVX agent that provisions the OVX integration bridge and speaks to the OVX API to provision OVX. So nothing fundamental here. That's kind of cool. I like that. And as far as the API, we've mapped a create network call to five calls within OVX. The first one, it creates a network in Neutron. We spawn a controller via NOVA. And we get the topology from OVX. And from there, we create a giant virtual switch network in OVX. And we start that virtual network. For subnet, we don't really map to anything because subnets don't really have a strong meaning in open flow networks. And for port, we create the port in Neutron. We create a virtual port in OVX. And we connect the two together. So let's have a look at how we could do topology extension quickly. So assume you've designed yourself this wonderful virtual topology. Well, you take that network specification and you pass it to the Neutron topology extension. That, in turn, passes it to our embedder, which right now is a very simple embedder. And it creates the virtual to switch physical mapping that is passed to OVX, which will implement and spawn the virtual network on the data plane. So we currently have a couple of deployments. The first one is a cluster deployment at Stanford, where this deployment will ultimately be the first deployment for OpenCloud. So OpenCloud is a project led by Larry Peterson in Princeton. And it pushes the idea that everything is a service. And if you want to know more about it, come to me. I can give you some pointers. But the main thing here is that, like I said earlier, OVX controls all these OpenFlow devices and allows you to spawn virtual networks for all the different services. Our planned deployments are an internet two nationwide deployment, interconnecting multiple campuses and running OVX as their networking. And each of these campuses is an open stack domain. And ultimately, all these campuses will be connected over the internet two backbone via virtual networks spawned by OVX. We're not quite there yet, but we're working towards that. So we're in the next steps for OVX. We're going to implement virtual network pausing and virtual network snapshotting and migration. So that's really cool, because that means that now when you migrate your VMs, you can also migrate your network along with it, which is kind of useful. We'll add some external connectivity, which OVX doesn't really have right now. And for the Neutron, we're going to provide Icehouse and Juno support, the topology extension, and a general purpose and better. So OVX is an open source, open flow network virtualization platform. It supports the dynamic creation of virtual networks and provides the ability to specify your topology as well as your addressing that you would like to use. So it's available at openvertex.org. And since we're open source, we'd love your contributions. So I have a demo. Does anybody have questions before I go on to a demo? And what metric do you want? So the number of end nodes or number of switches? End nodes. So the number of end nodes, we can go up to millions of end nodes. We haven't scaled it up, because we can add as many end nodes. We can add as many. There's a small trade-off you have to do, because the tag we insert eats up some header space. It's not encapsulation, but we rewrite packets. And so we eat up a few bits. And depending on how many virtual networks you want to have, you trade it off for a number of end hosts on a per virtual network basis. So there's a trade-off there. But you can easily support hundreds of thousands of virtual networks as well as hundreds of thousands of virtual of end nodes. Does that answer your question? Anyone else? It works in conjunction. So we actually, we don't require it. But for optimal performance of the system, we actually require an edge switch that can do a lot, well, do rewriting at, basically, at near line speed. So OVS right now is probably the best edge switch that you could have. And we rely on that. We don't replace anything. We're a controller. We sit in the control plane. Yeah, I mean, OpenDalat is a controller. We're a controller as well. But we're more focused on OpenDalat. Well, we do network virtualization only. OpenDalat does a whole bunch of things. Anybody else? Sure, yeah. Well, so right now it's a single instance, which is a single point of failure, obviously. But we have preliminary implementations which are distributed. So you can easily have, because I guess I could try and show that. Let me see if I have it. So this is basically the architecture of OVS. And the real intelligence is in that map right there. That's what maintains the mapping between the virtual elements and the physical elements. That map can be relatively easily distributed. And it doesn't change often because you're not creating virtual networks and removing virtual networks all the time at high rates. So it's easy to distribute. And using that as you distribute this, there's roughly no state anywhere else in the system. So you could have multiple instances. And it distributes quite nicely to OVS and open-flow switches. All right, should I go ahead with the demo? So what you have here is the OVX UI. On the left-hand side, you have the physical network. And on the right-hand side, you'll have the virtual networks. And what I'm going to do now is I'm going to create two virtual networks. And what you're seeing here is a network growing. And basically, I've created two virtual networks. The first one is a physical copy of the physical network. Sorry, an identical copy of the physical network. And the second one is a giant switch. So if I mouse over here, you can see which switches these devices are mapped to. And if I click on this, we see there's a single giant switch that maps to all the switches in the physical network. And what I can do as well on this UI is I can create some traffic. This is not something you want to do in deployment. It's just for demo purposes. I can create some traffic. And I can see the rules installed in this virtual open flow switch. And I can go over to the physical network and click here. And I can see some other rules that are the ones that are installed on the physical network. So now what I'm going to do is I'm going to create the three virtual networks. And you'll see those will be created nearly super fast. So there's one that's already been created, another one, and a third one. So let's have a look at this guy. So this virtual network is basically a ring of giant switches at each of the major cities in the US. That's kind of what that physical topology is made up of. And you can see a bunch of giant switches. And if I mouse over this virtual link, I see that it's made up of multiple physical links. And again, I can send traffic across these links. And this is actual traffic. We have an emulated mini-net network that runs all this. And there's actually traffic going between these links. And so again, if I click here, I can see the flow tables here. And if I click here, I can see that the MAC addresses are completely different. And that's because there are MAC addresses that we use exclusively for virtual links. And these virtual links, the first three bytes of our MAC address is our OE. So no one can collide with us there. And that's kind of good. We don't want that. All right. So what I'm going to show you now is, here we have a couple other virtual networks. It's just to show you that you can have networks of any shape, any form. They're all mapped onto this. All five of these networks are mapped onto this physical network. And what I'm going to do now is I'm going to go back to the giant switch. And I'm going to start some traffic. Sorry, it's kind of hard to do things like that. So now you see traffic going from, essentially, from down here all the way across and up to here. And if I tear down this link, what you see is OVX reroutes the traffic away from the broken link. That's kind of cool. You change nothing on the virtual network. It just reroutes it away. It's actually a funny anecdote. We were running multiple demos on top of OVX, on top of Internet2's backbone network. And they actually experienced a fiber cut between LA and Houston. And OVX reroutes the traffic of all the demos over alternative paths. And no one saw anything. We just had this little dotted line between LAX and Houston. It's kind of cool. And so with that, I'm done. So kind of early so you guys can go to lunch early and not have to stand in line. Any questions?