[MUSIC] Hi. In this lecture, we're going to be introducing the architecture of software defined networking, which, as we will see later, has important applications to networking in the cloud. The problem that SDN, software defined networking, is addressing, is one of complexity of existing networks. Networks are, in a sense, just like any other computer system, or system with software. There's hard problems we're trying to solve. And even something that looks simple might not be easy when you actually go to code it. But worst than that it's a distributed system, and even worse than that there are no clean programmatic API's, only knobs and dials to control certain functions. And if we're staying within a limited use case that might be good enough, but if we have a large, complicated, heterogeneous network where we're trying to use it in more interesting ways, as we will see, it can be very hard to build the network. A second problem is that network equipment, traditionally is proprietary. So there are integrated, vertically integrated solutions where a major vendor might produce its own hardware, its own operating systems and software and implementation of protocols and then configuration languages for that system, for that product. The result of all of this is that It has become harder to innovate in traditional networks. To build new kinds of networks, and new services, or use networks in ways that maybe we didn't expect, or more efficiently. So innovating and changing networks became a process a that has been often rather frustrating and time intensive. So in a traditional network, you might be configuring a router, for example, for BGP routing, in this trivially simple configuration file. It can get much more complicated than this. But then you'll have many of these also for many different routers. Hundreds, thousands, tens of thousands network devices, router switches, and firewalls throughout the network that will get pushed out to the various devices on the network. Once it reaches a device then these configurations have to be interpreted by router software and implementation of protocols that run distributed algorithms and arrive at routing solutions that produce the ultimate behavior that's installed in the network hardware. So if you look at this picture, what it's illustrating is that the policy of what we're trying to achieve is baked into the mechanism. So for example, the kind of network routing that I do, whether to achieve low latency or high utilization of the network, those controls are baked into the distributive protocol that are in standardized implementations. That not integration of the policy goal and the mechanism for achieving that goal means that it's hard to innovate. So let's move to software-defined networking, where we want now to produce somehow build a more programmatic architecture. How are we going to do that? Well, if we think about how traditional software and operating systems are built, it's based on layers and APIs. So we begin close to the hardware. We want a simple, low level interface that gives us pretty direct access to what the network switching hardware is doing. An API into the data plane of the network. Then we'll have a logically centralized controller that communicates with these distributed switches and other devices in the network. The goal of a logically centralized controller is that we can express our goal in one location. And keep the widely distributed switching gear as simple as possible. So we put the intelligence in a logically centralized location. And then on top of that, once we've got that central controller, we can build software abstractions that help us build applications, a network operating system if you will. So these features of a low-level interface, programmatic interface for the data plane, a logically centralized controller that allows us to build abstractions on top of it, are key ideas that come together into this architecture called software-defined networking. Let's look at a simple example from a very early SDN controller called NOX. Okay, so this is how we are programming the network at that central controller. And what we're trying to do here is to identify a user's traffic. So we want a particular user or computer to send traffic through the network, and that traffic through the network is going to be tagged with an identifier, a VLAN and that identifies that user. So to instruct the network to do this, we're going to match a specific set of packets that are relevant and we're looking at the location where this traffic comes in from as well as the Mac address. And we're going to construct an action that should happen, in this case, tagging, adding that VLAN tag to the traffic. And then we're going to install that action on the specified set of packets in a particular switch. So we're basically explicitly telling the switch, if you see this, do that. Now this is something that would be pretty difficult in a traditional network where I've previously done a lookup in some external database to figure out what VLAN idea I want to use for this particular user at this particular moment in real time and now I'm programming the switches. But here we can do it in a few lines of Python code. So this is an early and pretty low level way of programming SDNs, but it illustrates some common primitives, least common denominator, if you will, among SDN controllers. And one that this example is illustrating is the ability to match a group of packets and execute actions including re-writing fields in the packet and forwarding or perhaps dropping that traffic. In addition, commonly STN controllers will have some kind of typology discovery, so you can see globally what the network looks like. As well as monitoring so we can monitor rates of traffic flow, congestion, packet loss and so on in the various switches and routers and other devices in the network. So there's a lot more ways we can think about SDN, but these are the least common denominator for SDN controllers, the ability to control traffic and discover the topology and monitor behavior in the network. [MUSIC]