 Okay, we're gonna continue our afternoon of networking related talks here in the technical deep dive track and the talk that is up next is about open stack and open flow. So please welcome Samrat Thank you. I'm Samrat. I am from NEC corporation working on the open flow and We have long history in this area From NEC working with Stanford to bring the whole open flow and the software defined networking Into production slowly. We're also seeing the how it has synergies to work with the open stack. So this talk is basically about Giving a primer on the open slow and the STN and how it fits into the open stack architecture So this is just a brief introduction the open so in case, you know, some of you who are not aware of it I guess, you know Right in these years or in the last past years people are all getting aware of what the open flow means if what you have here in the open flow is that you have a switch and Then you have a controller and the controller is continuously or dynamically programming the floatables in the switch so that it can change the forwarding behavior of the switch in a dynamic fashion and the way it wants it and by that it also Enables a more a sort of intelligence and automation into the network the second more important part of this whole open flow protocol is that it is open and It allows you to work with Multiple vendors. So the way typically the open flow protocol works is that there is a there's three things There is a rule which is the matching criteria on the packet header fields and then you have the action which basically says what you want to do with the Flow packets whether you which port you want to forward it to whether we're going to drop it or pass it And then you can also gather information from the switch So the important part why we are talking about open flow and in relation to also open stack is the openness of the Openness of the interface to the switch that you can have a controller And the controller can be either an open source controller or can be a proprietary controller But the important part is that the data plan is open So you can have multi vendor switches which supports open flow Become a part of your network and you can choose which vendor to bring in to create your network So here we start with the premise of this talk So what we understand is that the open flow provides a switch level model which basically allows you to go and program the switch and You also see the The cloud orchestration model from the open stack which gives you the quantum and know when the rest of the things But particularly we are mostly interested in quantum and nova which participates in the whole network behavior But what we want to know by this whole talk is that What is the middle ground between them? So you have a switch you have the orchestration who provides the network model from switch to the orchestration So that's the part we are going to discuss initially in this talk and in a simple sense in network model means that you know as you all understand is about you know give me the service to create a network and to attach my Instances of the VMs to the network in a automated way. So the the question here is that what is the Appropriate network model which connects these two parts So in a conceptual architecture Again, you see is you need a network model and that connects the orchestration model So the orchestration model can help to provide this to a service or consume them now coming back into What you need in a controller or a software defined network controller is that you need first is a open-flow control so that you can go and Control the different open-flow switches which can be a virtual switch which can be a switch from any vendor which supports open-flow But on top of that you need a network control because just the switch control will only provide you so much you know it can only go and configure maybe an OVS or Maybe one physical switch, but you know the there can be a complex network topology of multiple switches Connecting to multiple virtual switches. So someone has to consider about how do I do the end-to-end routing between? You know the appliances or between the VMs So that's the network level control you want right and then on top of it You need a model because without the model you do not you cannot create an API framework That can be consumed from the top orchestration layer or the open-stack part of it So that comes the plug-in, but before you need to before you can create a plug-in you need is some sort of a a model that can Define such a network, which is not just a switch base, but end-to-end best So that is where we come to is some sort of requirements based on which You know we have been working on such defining such type of a virtual network model but it came out from the software-defined network standpoint and We'll see that how it actually relates to the APIs in the quantum side as well But before going there want to know like what would be such requirements, which we are trying to capture here The first is that you you're capturing the network virtualization. It's an important part which is required to create services on top of it and One of that virtualization is that it cannot be just on the the virtual Switch world, but it also has to capture the physical switch So it has to be a network view that Spans from the virtual switch to the physical switch to the entire center network in that case And it also has to support the multi-tenancy which we all understand from the open-stack world And then it has to have the ability to control and into a network from VM to the VM or From VM to the appliance or to the gateways The the second part which is very important in the in the case of open stack is that it Requires an on-demand provisioning So it can't be a network which is pre-created It's technically defined a pool of resources which you just go and absorb But it has to be a network that creates created an on-demand fashion Can be deleted an on-demand fashion and also it has to have the ability to be configured because you always are seeing a lot of changes in the whole you know System in terms of where the VMs are getting deployed where they're scheduled where they're moving and In added to that the part when you're talking about the physical network You're also talking about a lot of optimization issues When you're talking about let's say high-performance bandwidth or you're talking about Resiliency or redundancy in the network when you have a multi-hop network between the VMs So so who is going to take care of that you cannot bring out all of that? level of Optimization back into the orchestration layer so certain things has to be hidden But they has to be a part of their whole network provisioning And the third part when you're talking about again a Entire cloud level orchestration you have to also consider that it can't be tied to a particular topology It can be like you know, this is a more vendor proprietary Architecture you have to choose or there cannot be things like constraints about Vlands Or they cannot begin like location type of things like when you're talking about VMs Which can move from one place to another so these are the three main Requirements which can define a good network model that can then be consumed by the top quantum level Services So how does it look like in general what it what it essentially has is the a Switching link which is an open flow type of a network and the opens on network is Using the open flow control and what you want is from the switch model to go to your network model is a Is a virtual tenant network that actually we define here and the virtual tenant network allows you to create multiple Virtual network each is defined in an independent way They can have their own ways to define what network policies what are the endpoints you connect They essentially reside independently In a way that it doesn't interfere, but they all reside on top of the same physical network So the whole network model which we have been talking in terms of the requirement is a layer Which need to add on top of a controller which is talking open flow to all the switches that can create such a expulsion of the Resources in a abstract model and that is the virtual tenant network model Once you have such a model Then you can then think of that what would be the right API's and that can be consumed by the higher orchestration layers So here is a way the model is created and the recommends which we have been stating so far so it's a it's a model which is very much looks like a Network model as opposed to an object type of a model. You can see here. There is a topological property here So you define virtual bridges Which actually represents a? particular layer to network and Before defining the virtual bridges, let me say the entire network actually represent a tenant very much like what you see in a project Basically maps to a tenant in this particular case now once you go inside that network You have the virtual bridges and then you have the virtual routers Which can connect, you know all the layer to network and then you have virtual links which are essentially defining your abstract virtual network topology and the in the square Parts are the points where it finally connects to the physical world And the physical world can be a physical host. It can be a Virtual machine can be a physical appliance That's the part which maps the external world into the virtual network world and Then this entire virtual network and then we translated into the physical network But the controller make that happen automatically Where the orchestration layer or the one who is trying to define that doesn't have to worry about what the physical network is or how? The virtual switches are connected into the physical network So you're creating an abstraction layer which hides the or I would say decouples the physical network connectivity the switches the Configuration of switches totally outside the boundary of how you are using the virtual network from an orchestration automation standpoint So here it shows scenario where you can have a different virtual tenant network that each tenant can have their own ways to define one can just have a Layer two network another can have multiple layer two networks connected by A router and they all can be Overlaid or Deployed I don't want to use the word overlay It's our physical network deployment. They all virtual networks can be deployed on top of the same physical network And they can work Independently without affecting each other So that's that's the general view of how you are defining the multi-tenant virtual networks in the case of a software defined network So now let's come and connect to the quantum Side of it. So in case of a quantum what it wants is it also needs to create a Dynamically the virtual tenant network. It has the concept of the project. It has the concept of the network So what it wants is that it wants in a simple case Give me a layer to network and also You can you want to add or delete or modify? The whole virtual network or the layer to network Depending upon how the VMs are coming in and getting connected through the OBS or even in a physical network thing and What the opens the network controller is supposed to do is that it should? Automatically detect the the topology of the entire network again Which consists of the virtual switches and the physical switches and how they're connected It should ensure that however the VMs are connected the way The VMs are connected to a particularly to network accordingly the controller has to go and Dynamically install the flows in each of the switches so that they are connected and as I said at the same time it has to support all the features which someone wants in the actual network which means Multi-path or Intuit reliability or flow migration in case of VM migration All of that has to be also a part of the thing So it can't be just like you know I get connected But it also should provide with some of the optimization which which brings the physical network and the virtual network together So here is a simple scenario where you know you can Think of a deployment it's orchestration layer which basically Creates the Network and create the subnet so it comes to the quantum the NEC plug-in which is open and downloadable and Now available with the Folsom so that basically then Talks to the open-flow network controller So initially when you create a network a V-bridge is created because it represents a layer to network and at the same time and automatically a DHCP agent is also created and you can see they are essentially connecting to the external and the external is connecting to the V-bridge to the virtual link so that's your first level of Creation of a virtual network which happens when the quantum is called for creating a network and This is gone back to the controller the controller will ensure that you know that is deployed in whatever switching topology you have in the underlying network So let me show at the same time some demos at the while we go through the talk So this is a simple demo. I'm going to show where we have two open-flow switches They are from NEC and they are controlled by a dual redundant controller For reliability and then you have to host with let's say two VMs So here is a network creation You are providing the network name and then providing the Network block the gate phase option, but we are providing the gateway of the router So you have the network created but now let us go into The So this is actually the controller interface It's not that someone has to see that but it is just to show you what is actually happening in the controller when the network got created from the horizon so here we are actually in the controller server and We are trying to show you what has happened By running the status of the configuration so you can see here that there is this There is a script which corresponds to the Virtual network that got created. So there is a V bridge definition So is a bridge was created for the layer to network There was an external created which was actually mapping to the DSP agent and then there is a building which was created to connect them So I think I missed you another part. I'll show you So this is an important part in the also from the same user interface which comes from the controller You can you can see here That the topology which is shown in the demo There is a two virtual switch connected to the two physical switch and in the left side You can see that's a virtual network which is representing the one of the virtual bridge for the layer to network got created So that's a very simple thing. You can see here when you're trying to create a network so now the next part is I want to create a Instance and I want to connect that to the layer to network which I just created so The orchestration system asked the Nova scheduler or the Nova scheduler to the Nova compute to create a VM and Then what it does it? It asks the quantum to create a port and From that port it gets the port ID the virtual port ID, which which is there? To for the network and also the MAC address And as we know the quantum will go and back to the DSP To ensure that for that MAC address there is a static IP address mapping So once the Nova compute get that it all creates the tab device for the OBS and then it boots the VM So what the NEC agent? Or it is any agent essentially which is sitting there It is doing is it is basically trying to see is there any new tab device Which got added into the whole system and if there is a new addition of the devices What it gets is it gets the actual the virtual switch port ID Or the port which refers to the virtual switch The DP ID which refers to the switch ID essentially from the open flow context And the port ID which was given from the quantum and it sends it back to the The plug-in which is residing in the quantum so Given the port ID Given the obvious port and the DP ID these two basically tells you that what switch and what port The new VM got attached now This is enough for the plug-in to go and create an External into the virtual network and then connect attach the VM to To add into the virtual network So you can see now the virtual network which was originally only had the DSP agent now has the VM With the external and then external got connected to the Virtual bridge now your network has changed and it has attached the new VM into that So in this same way you have new VMs coming into the Being created from the Nova compute in any of the host machines. They all essentially are adding into the Virtual network and the same process can be also be done for deleting as well So in the case of a delete the agent basically just sends the port ID Back to the quantum and it deletes the port ID the quantum NEC plug-in knows for a given port ID What is the obvious port and the obvious DP ID? So he basically removes it so in that way you are able to add as well as you have to delete the point is now the plug-in is able to go and change the The virtual network in the controller and the controller using the open flow is able to dynamically change the entire network setting Whether you have a to switch network, which you are showing here or a hundred switch network So to show that let's me show you demo for instanced creation and You can see here that at the right side you have the four switches The two virtual switch and the two physical switch in the left side, which is that virtual network. There is only one VM which is connected to that which represents a DSP So we're creating the first VM here choosing the instance name and Then we are connecting into that network, which we just created before So this first VM was created then we go and create a second VM You want to show finally they can connect otherwise There is no meaning to just getting attached to the network, right? So it's the second VM. We are creating. It's actually the third VM. We are creating here So you can see there there are Three VMs Starting with 176 which are getting created here Now let us go back here So it had one just which was represented the DSP now going forward We're just refreshing that and It shows you that there are three VMs which got attached to the virtual bridge and that all happened based on the successive triggers which we were discussing here from the Nova compute to the adding the device getting to the Plug-in plug-in essentially changing the VTN and then it is deploying that so let's see going for forward We are going to go into one of the VM and Then we are going to ping to the other VM which we just got created here So you can see that the ping is working between the two VMs We just got created an entire thing was automated right from creation to connecting to the network and then creating the The flow table between the physical switch Spanning the virtual switches and you can even see the track the flow here Show you like you know how the two VMs are communicating here Same thing you can actually track in the physical network as well Yeah, this shows you how the one of the VM connected to one of the switch Virtual switch goes through the physical switch and then goes into the other VM so this gives you an idea of how the at the age the VMs were able to go and attach and finally the controller is able to go and Patch the end-to-end network by controlling the flow tables in each of the purchase So this is what you can see as the overall picture of when you're essentially deploying such a system You can have a different type of network topology Which is connecting your host and you can have OVS which are holding on to different VMs and what you're able to do is you're able to do automatically end-to-end Forwarding so which means you do not have to worry about today. You have two switches tomorrow You go and connect some few more switches, you know add more capacity change the links. You do not have to worry from the Open stack viewpoint because all of that is essentially taken care by the controller Who is automatically detecting the topology and ensuring that when there is a VM Which wants to communicate how to create the path? Secondly, it is creating you giving you the with the multi path. So you are able to do Get more into an bandwidth and not just limited to layer 2 but also layer 2 and layer 3 Third you're getting redundancy in the network. So any link goes down any switch goes down It is always going to create backup bot. So your your traffic is always Yes, yes your paths are always there between any of the VMs and The last part is you know respond to changes Which means that in there is any sort of change in terms of addition of VM in terms of Changing the layer to any of those things. They're all basically responding dynamically and To how the flows get set up So and the next point is because of the virtual network definition You're also ensuring that all the virtual networks are isolated, which means if these VMs are Belong to the same virtual network or even the virtual tenant network So they cannot go and talk to the other VMs So all that isolation at the level of the project at the level of the layer 2 networks are all essentially defined from the virtual network standpoint and the another important part we want to say here is that because this entire network is Location-free, which means you're not actually going and doing any sort of configuration into the ports of the switches Your definition or mapping is essentially totally port-based, which is happening at the V switch level. So because there is no particular Bindings of a address block or a VLAN into the switch plane You can easily move the VM from one place to another place Because your definition actually is defined from that virtual network, not from the physical network So as long as your VMs are essentially connected to the right virtual network It will remain a part of the same virtual network into where it moves. So let me show That video it's a little bit complex But ideas to just give you a flavor of what is happening here So we want to check on to one particular VM which is connected to the same network and We are going to go and do a live migration from one host to the other host Which is getting connected to a different? OBS So right now the migration is happening So in the left side the virtual network there's no change because even though the VM has moved from One host to the other host it still is the part of the same virtual network topology Because it is still connects to the same V bridge, which is the same layer to network But in the right side which shows the physical topology. That's where the change has happened So we we go here and see all the icons which are connecting to the the physical Switch now we will will ensure that you know it So you can see here the the one which got which was initially connected to the virtual switch one ninety two one sixty eight eighty one hundred That link is gone So essentially what happened was that particular VM when it got moved that that particular external is no longer there So the controller Essentially has taken out that particular external from there instead it has added a new external which you can see in the left side Because the VM has moved from the right side of the V switch to the left of the V switch So this this is a good for illustration It is not someone has to really care about when they're doing it But it shows that you are able to move the VMs freely across the network from one V switch to another V switch without have to worry about Whether you know your switch has to be provisioned with the right V lands or you have to change the V lands any of those things So this is a typical deployment scenario. So essentially what you need is a for deployment of such a system you need a management network which connects your controller and then What you need is the cloud controller of the open stack node where you have to Deploy the the NEC plug-in and the NEC agent the agent is the one actually which essentially tracks the the port the tab devices and and then communicates it back to the plug-in for adding the VMs and deleting them and Then you have the compute node which basically has just the agent part So once you have these three components you can then attach that into any Devices open-source devices and get the entire network end-to-end Automated connected and provisioned in a non-demand way It shows that some of the open-flow interval switch. Well, I'm giving a talk here in open stack There is another group in open network summit in back in San Jose and This basically showing that you know, what are the different type of switches which are now Are participating in the open flow for you to select and create your network So there are many such vendors. There are more vendors coming in They're all supporting open-flow 1.0 and then going into more the 1.3 support, which has more advanced features So it's a great choice for anyone that you have the flexibility to choose Between so many different vendors actually this was a class topology created with certain features Which difference which vendor provides like whether it's a 40 G switch or 10 G switch or a 1 G switch, right and then you have the opportunity to Automate the entire system end-to-end and you do not have to worry about The configuration and the optimization of the entire network, which is totally taken care by the controller Plus the controller is not limited to just these simple features Which is about creating a layer-to-network and adding that also brings the value of having the same L2 and the layer 3 defined at this point of time the the layer 3 network APIs are not yet mapped to the controller Layer 3 APIs, but in future that will be done where you will be able to do even the layer 3 provisioning through that without Have to go through our layer 3 agent, which is the current the traditional Framework, which you have in the open stack Addition to that there are other features which are coming in like you know, how to add ACLs into that or how to Bring in appliances into that. So these are basically where We need to figure out how the quantum APIs Can be mapped into these more advanced features into that. So this is a great start This is a start where it allows you to do simple network, but it still gives you a lot of optimization Automatically from the underlying network So that's sort of the end of this Talk, which is basically created to give you an introduction Onto how the open flow is being used in the open stack, but for further information Or for trial you can contact us where you can learn more about How they can be deployed or what are the issues we are seeing or you know, how they can more information about SD inside of it. Thank you very much So the question is that if you have a deployment when you have Overlapping IP addresses between different tenants. Yeah, that is possible here the The controller or the open flow Can have different virtual tenant network with overlapping IP addresses But within a particular virtual network, you cannot have Overlapping IP address between two L2 domain the architecture. Is this what you're asking Yes, so this picture if you're asking the question about the IP addressing in this particular case so You know if you leave out the management and the secure channel Which is basically connecting the old the system once you come into the data plane. They are the flows are essentially defined Where they are segmented from a Tenant standpoint, which means that a particular tenant whatever he does Whether he creates what IP address or he's laid to definition does not impact the other tenant There is a flow level isolation in each of the switches to ensure policies of one does not Go and impact others so today you have multiple organizations and they can have their own network today What the problem is one organization trying to do something can go and make the entire network inconsistent This is not going to happen here because there's a full isolation between the Definition and the policies of the virtual networks here Okay, so the question is that every time there is certain changes happening in terms of adding a VM or Migration of the VM or any changes does the controller go and changes of floatables in each of the switches? Okay, so that's the question is different. So what you're asking is that if there is a lot of traffic going on Then is there some sort of a change in the floatable to balance the network? Exactly, so what happens is in the multi path So it it what it does is that based on the load of the network it will create up to eight paths between any endpoints and it does that by automatically detecting the topology and Finding out if there exist Such alternate paths to balance the traffic and that is totally done by the controller Okay, so the question is that if it is a pre-configured or dynamically done. So it is all done dynamically All you can you have to specify or you can specify how many paths you want to use after that The balancing is done dynamically. Okay, so the question is that in the migration? I'll just take his question last It's a good question. So in the migration you are actually moving on the same Layer to network But you are moving from one physical virtual switch into another virtual switch When you're when you're moving it you are talking about whether there is a layer 3 Network we are crossing or not remember an opens on network is not a layer 2 or a layer 3 network That's a definition, which is at the virtual network level The at the opens the switch level It just means that something has moved from a particular given port into another port And I have to ensure that he gets connected based on the definition of layer 2 or layer 3 absolutely nothing The all you're doing is the controller automatically goes and changes the floatable entries, but there is nothing you have to do You do not because there is no concept of boundary The boundaries are defined in mostly in a legacy network where you have the concept of a subnet and VLANs So you're crossing boundaries. Let's say from a routing boundary right here. There is no concept of a boundary That's why it is called a location-free network essentially. So I think Time is up, but if there is any further questions, you know, you can either contact me or we can discuss it later Thank you very much