What SDN does it illuminates the key drawbacks of the original Active Network vision. And the reason why it eliminates that is first of all, it's rule-based routing. Earlier in the Active Network vision I said that code is being carried by the packet and code is being executed in the routers. That's no longer the case. What we're going to do is we're going to do rule-based routing as opposed to executing arbitrary code in the routers and this immediately removes the protection and resource management threats that we talked about. The second thing is that the routing for the flow is done one centrally, and then once that is done, each of the routers can work at line speeds. So think of it as the tables that I talked about in the old style networks, the tables getting updated by the central controller. And once it is updated, immediately it can use that till that flow terminates and then you start a new flow. So that's the idea behind how the routing works. This immediately removes the poor performance concern of software loading because it's no longer the case that we're executing code. We are still doing routing at line speeds. It is just that the routs are set centrally through rules in the switches. And the the real breakthrough why SDN guard its adoption is because of the fact that we are separating the control plane. That is the plane that does this rule setting for routing from the data plane. Earlier the two were integrated together, right? So, the packet comes in, it contains the control information also. And that was the reason why you have to execute code to figure out where to go. That's not going to be very fast solution. On the other hand, in this case what we're doing is the control plane, even though the software control from a central entity, it sets the switches and then the switches can work at line speeds. And there are well-defined APIs to program the control plane. OpenFlow as an example. And in the workshop that we have associated with today's lecture you will be experimenting with building topologies and they're building the control plane using these APIs. So if you look at the architecture of SDN, what are the elements? Well, there is a switching fabric implementing the desired network topology, for example a Clos Network. And like I said, the Closs Network has nice properties, but it requires that the rule setting be done in a manner that is commensurate with the flows that are going on in the network at any point of time. And there is a central controller that is setting the rules for switches for the traffic flows that are currently going through the switching fabric. And the central controllers are programmed using the APIs provided by whatever the SDN architecture is. And there is state maintenance that is commensurate with the control application directives and the switching events that are going on, so that you can refine what the network is doing, and what the switches contain are the forwarding entries. There are set by the central controller so that they can take routing decision at line speeds. And the switch hardware itself is simple rule-based traffic forwarding, as instructed by the central controller. There is nothing very fancy about it. It is just that the tables are set by the central controller. And that sort of the architecture of SDN. And this concept of SDN has been used in both Wide Area Network as well as in the cloud. And the Wide Area Network is not the focus of our talk today. I'll just mention that the focus is Network-wide traffic engineering at-scale. That is Network-wide you have certain performance goals, and you want to meet that using an SDN. And of course, this is a much harder problem in the Wide Area Network because there are all kinds of traffic going on. And what is being tried to do is infering traffic patterns and then centralize the control so that the switches can be set appropriately. I mean, lots of examples of work that have addressed how to use SDN in the Wide Area Network. Some of them are theoretical work, and some of them are practical deployments. For example, there is tomogravity which is infering end-to-end traffic matrix. There is Routing Control Platform, was proposed which is a logically central entity for selecting BGP routes. BGP routes is the routes that are being constructed between different service providers for instance Verizon and Comcast as separate autonomous systems. And they need to communicate with one another to carry the traffic from subscribers to each of their services. And the BGP is a protocol that is used for that and that at that level they thought of using the same SDN concept. And there is a work on centralizing decision dissemination and discovery and data. And this was something that is proposed as a precursor to some of the things that have gone on in defining SDN for cloud data centers. And Google is the one that is well known for putting up this software-defined WAN which actually allows Google to control the traffic for the flows that they manage. And it is balancing that for capacity against the application priority using OpenFlow, which is the language that you'll also be getting familiar with. So this is the application of SDN in the WAN environment. And we are not concerned with that for the purposes of this course. We are more focused on SDN and cloud. And in some sense cloud provides the killer app for SDN. And there is sort of a perfect storm of need, control and personnel are coming together in the use of SDN for the cloud. If you look at it from the point of view of need, I already mentioned that we want perfect network traffic isolation among the clients. That's important. What that means is that, just as an extreme example, if I have a data center, and I have both Pepsi and Coke using my data center, I don't want each other to be sniffing one another, right? So they won't put the traffic on my data center if that is the case. So you want complete traffic isolation. That's one important consideration. And then you want perfect performance isolation for each customer. That's something that is important also. So that we can give layer to semantics or communication among them. So that is the need aspect of it. The second is the control. The control is coming about due to the fact that the network fabric in a data center is entirely owned by the the service provider, cloud service provider, as opposed to the Wide Area Network, right? So if I am a Microsoft or Amazon, the network fabric is mine. I can control it completely and that's an important attribute of the cloud, which makes SDN very palatable. And not only within the data center because now we have geographically distributed data centers. And even inter-datacenter network fabric is not open to all Internet traffic, but it is for a particular service provider. So, even in the case of Wide Area Network that connects together data centers, you have the ability to control the traffic and how it flows. And perhaps, another important consideration is that there are system developers, both architecture system software and network gurus, who are all aligned on a common purpose namely how to build scalable networking in fabric. And those are all the things that made it possible for SDN and it's adopted into the cloud computing framework. So if you look at the elements of SDN architecture in the cloud, there are these different building blocks that I've shown you in this picture. There is the resource manager, the clients coming from anywhere, a set of system objectives, a control plane as an element. And here is a networking fabric inside the data center. And there are entities called the monitor, and updater. And I'll tell you the role of each one of these things in the next slide. So if you look at the Resource Manager, it's job is to feel the request from the clients, and then decide what are the resource needs. And the resource needs are both in terms of computational elements, right? That needs to be provided for these clients, as well as how the traffic pattern has to be managed for a particular app. And in this picture we are not talking about the server allocation. We're only worried about the network allocation. And what the Resource Manager does is based on the set of clients that it wants to support in this data center. And given some system objectives in terms of SLAs for these clients, it says to the control plane, this is the requirements to be met by the network fabric at this point of time. And that's something that is given to the control plane. And the control plane takes that prescription and decides that this is the target state that I want to get to. And once it decides this's the target state that I want to get to, it can then set the rules for the network fabric. Saying, given the set of flows that I have to manage right now, this is what I want you guys to do in the network fabric, right? And once that rules have been set in the network fabric during the course of the executions, the switching fabric is just doing the routing based on the rules that have been set. But what is happening is we are continuously monitoring what is happening in the network fabric. And that results in what is called the observed state. This is the target state and this is the observed state. And what the control plane is going to do is compare these two guys. See the observed state is matching the target state that it wants to get to. If it isn't, then it says, that okay, this is not tuned properly, so I have to reset the rules so it can update the network fabric. And this is a cycle that goes on during the course of execution of these applications. One of the important things to understand also is that many of these clients are long-running clients, right? Many computation go for a certain amount of time. And so even though this rule setting is going to take some time, that is going to get amortized over the life of that application and the network processor it manages. And that's how we get to the performance advantage.
