[MUSIC] So what we just saw are some of the key ideas of SDN. A programmatic low level interface with the data plane, centralized control, and higher level abstractions that make that control easy. Now all of these ideas have long roots if we go back into the history of networking. No one of these ideas in isolation is something that's new. So we're not going to be able to cover all of that history but I want to talk about a few of the threads of evolution of SDN. So one of the important needs that SDN is driving towards is making the network flexible. And there are a few important ideas that I'd like to mention in past systems that allowed us to make the network more flexible in somewhat related ways. One of those is label switching or MPLS. Okay. Now, in terms of, the mechanism what MPLS does is actually simpler than IP Longest Prefix Match Forwarding, it does matching labels and executing actions based on those labels. The effect that we get from that is that we can essentially lay down any path that we want in the network for certain classes of traffic. That allows us to go beyond simple shortest path forwarding, and do more interesting and complicated things. Like good optimization of traffic flow to get high throughput for traffic engineering, or setting up private connections between enterprises and distributed sites. Okay, and that flexibility of programming a network and, in particular, oriented towards traffic engineering is something that made MPLS very successful, and as we'll see is also an important application for SDN. Now active networks made networks more flexible in a very explicitly programmatic way, by embedding a program within a packet header or a pointer to the program in the packet header, that the router switch should execute. Okay, now this is a somewhat radical idea of packets carrying code with them. But it illustrates that even at that time there was a recognition that we could do a lot more with networks if we could make them more programmable. Another important thread of ideas is around logically centralized control of networks, and this is something that goes back decades. But I'm going to mention a few projects that are more recent in the sphere of Internet working. One of these that was influential is the Routing Control Platform. So if you look at how routing is done with BGP routing, this is the Global Internet Routing Protocol. Even within an enterprise it's still a distributed system. You still have many exit and entry points where you connect to the outside world, and your global routing flow, even within your enterprise, is controlled in a distributed system. The idea of RCP was to centralize the decisions about routing flow, and then push out those decisions to the border routers within the network. The 4D architecture introduced an idea of a logically centralized decision plane that, like SDN, separates those decisions from the data plane actions. And that's very closely related, of course, to the idea of having that explicit API where you're programming the hardware. Now an immediate predecessor to SDN was a project called Ethane which allowed us to program policy for an enterprise. For example, access control in a centralized way and have it then pushed out to the entire network. Okay, so you would write a policy such as the one illustrated here about how certain groups of users and types of devices can access the network and then have that single centralized expression of the policy be implemented automatically in a distributed way. Now the OpenFlow protocol was introduced in 2008. And this is one possibility for how we have that interface to the data plane. So it introduced that explicit idea of the standardized interface to the data plane and with general purpose programmability at the controller. NOX was the first controller for OpenFlow that provided a centralized view of the network and exposed that to multiple applications with database style access. So the important idea here is that NOX can provide this service of the appearance of centralized control to the applications, where behind the scenes it's doing that work of state collection and state distribution in the distributive system. Sine then there's been an explosion of interest both in academia and in industry in Software Define Networking with essentially every major networking company having some sort of an SDN product. But if we go beyond the marketing, what is it that is the real fundamental, technical, opportunity here? Well there are, in fact, real opportunities that are pretty exciting. If we look at having an open interface to the data plane. From the hardware perspective, if we have a standardized API, it can be easier for operators to change hardware in their networks, to use different vendors, and for new vendors to enter the market. From the software perspective, we can finally directly access the device behavior, which exposes a lot more capabilities then we would have in traditional networks. The centralized controller gives us that direct programmatic control. So we can make architecting and network more like good software design. Okay, and then building abstractions in the controller allows up to solve these distributed system problems only once. And then, it's just a matter of writing algorithms. So, whereas, in a traditional network, if we want to devise a new way of controlling traffic flow in the network, that involves writing distributed protocols and standardizing. Now we can just write an algorithm like Dijkstra's algorithm. The kind of thing you learn in freshman or sophomore level computer science and plug it directly into your STN controller. So we can control networks in a way that's much more like traditional software engineering with libraries, with languages to help write programs. And if you don't want to write programs, perhaps we can build systems that allow you to express higher level goals. Like I want my network to have optimal traffic flow or this certain kind of access control. So those are real exciting opportunities. But at the same time, there are certainly challenges. So one, of course, is performance and scalability. Where we're controlling the network through devices that are going to have to respond quickly with latency concerns, for example, and capacity concerns. And although I've talked about a logically centralized controller, I'm careful to use when I am careful I use the word logically centralized, because, in fact, we can't have a single centralized controller. All of those distributed system challenges are still precedent that are present in a traditional network. The network is still fundamentally a distributed system. Which means there are hard problems surrounding resilience, the lack of perfect knowledge of everything that's going on. We never know exactly when an event happens. And consistency issues between the multiple controllers that we will need. Moving beyond purely technical challenges, there are architectural questions that academia and industry are exploring. One is what should be the protocol to program the data plane? Should it be OpenFlow which itself is a standard that's evolving. Something that allows more network function virtualization. That is, there's more general purpose compute embedded in the network devices. Whitebox switching or programmable data planes. We're not going to talk about all of these and certainly it's likely that there will be multiple solutions for different use cases. But this is a space that is actively evolving. As is the space of what are the right higher level control abstractions that run at the centralized controller? Looking at the OpenFlow protocol, or even the early NOX example that we saw, that's far too low level for most of what we want. We generally have a goal, something you're trying to get done in the network. I want this part of my network to be properly segmented or I want traffic to flow through load balancers properly. I want to express that high level goal without worrying about the low level details of matching certain fields and packets, right? But what are the right abstractions that can cover a good set of use cases and whether we need special controllers for special uses? These are questions that are, again, evolving. In the context of those significant challenges we have, however, seen deployment of software defined networking. And with those challenges it really takes a killer app. So what were the early killer apps for SDN? That's an interesting question. And another interesting question is, I haven't said anything about cloud computing so far in this lecture, where does the cloud come in? Well, it turns out that a couple of the early killer apps for SDN were very relevant to the cloud. One of them is virtualization of multi tenant data centers. Where we have tens of thousands of tenants for which we're spinning up VM's and virtual networks in real time, very well suited to a programmatic model. And second inter-datacenter traffic engineering; where we're trying to drive our expensive network that connects our cloud sites to the maximum utilization possible. All right, because in the wide area we want to get every bit of bandwidth that we can in that expansive network. And again this is something that if we want to get the best possible utilization we actually need more interesting algorithms that is, again, very well suited to an SDN programmable model of the network. So, something that both of these use cases have in common is that they were special purpose deployments, targeted towards a specific use case with less diverse hardware and controlled by one entity, which made the deployment easier. And second, they were applications, where the existing solutions weren't just a little bit inconvenient, they wouldn't work. They wouldn't have achieved the goal. So, what we're going to see in the upcoming lectures is focusing on these particular use cases, in the context of cloud computing, and looking at case studies for systems that were built to address them. [MUSIC]
