Welcome back. We are beginning a new module studying the applications of software defined networking in the wild. This first lesson will study applications of software defined networking to solve problems in real world data center networks. One of the killer applications for data centers is cloud computing. In cloud computing environments, clients can take advantage of the fact that a network of tens of thousands of servers, that is shared among multiple tenants, can be scaled dynamically for that client as demand fluctuates. If a client suddenly experiences a surge in demand, the data center provider can quickly and easily allocate more resources to that particular customer. Data centers typically have multiple tenants or independent users. Thus, allowing the operator of the data center to advertise the cost of the shared infrastructure. There are many different service models for cloud computing. One is called software as a service. Whereby the provider licenses applications to users as a service. The customer, thus, avoids the costs of installation, maintenance, patches and so forth. A second model for cloud computing, is the platform as a service model. Whereby the provider offers a software platform on top of which a customer can build applications. The customer can avoid worrying about the scalability of the platform, which is taken care of by the data center operator. The third cloud service model is the infrastructure as a service model. Whereby the provider offers raw computing, storage and network resources, thus preventing the customer from having to buy servers, and estimate resource needs in advance. As we have previously discussed, one of the key enabling technologies behind data centers is virtualization. Or the ability to run multiple virtual machines on one shared physical machine. Applications can run unmodified exactly as they would on a real machine, but the data center operator can migrate virtual machines from one server to another in response to fluctuating demands or changing traffic patterns, without the knowledge of the customer. The ability to support this type of seamless virtual machine migration is made easier if the data center network is constructed as a single large layer two topology. General speaking, generally speaking, data centers have a number of design requirements. One, it is the easy migration of virtual machines for the reasons we just talked about. Another is that the switches in the data center should require minimal configuration. A third requirement is that the pairs of servers in the data center should be able to communicate along efficient forwarding paths. The typology should not have any forwarding loops and failure detection should be fast and effective. Before we talk about the role of software defined networking in data centers, let's look at a conventional data center typology as they existed before software defined networking. In a conventional data center topology, the core of the data center was connected to the internet with layer-3 routers. The servers at the edge of the data center were connected to one another with layer-2 switches, and this access layer was connected to the core with aggregation switches. Unfortunately, this type of topology presented a number of drawbacks. The first is that the core routers presented a single point of failure. If any node or link failed in the core, servers at the edge might not be able to communicate with one another. Second, links higher up in the topology might become oversubscribed. A solution to the problems presented by this conventional topology is to design the data center as a multi-rooted fat tree, where capacity increases towards the roots of the tree. This topology design not only alleviates bottlenecks toward the core, but also provides inherent fault tolerance, since any server at the edge of the data center topology has multiple ways of reaching the core or servers on other parts of the edge network. To satisfy the design requirements we set out for ourselves, there is a need to construct a data center as a single large, layer two topology. Such a topology is, of course, plug and play and requires minimal configuration. Yet, this approach introduces many scaling problems. The state required to implement that layer-2 forwarding at all the switches in the data center, potentially for all the hosts. We'd like to avoid flooding of ARP requests and other broadcast traffic across the entire topology. And we'd like to be able to update address mappings quickly when virtual machines migrate from one part of the data center network to another. Software defined networking helps us solve many of these problems. The PortLand design introduces what is known as a fabric manager, which is like an SDN controller. This logically centralized fabric manager in combination with positional pseudo MAC addresses, allows a layer two network to scale to tens of thousands of servers inside a data center. In the PortLand architecture, each host has what is known as a pseudo MAC address. The pseudo MAC address is hierarchically structured, such that all of the servers in the same pod have the same prefix on their pseudo MAC address. This stands in contrast to a conventional MAC address, which is completely flat. The hierarchical structure of the pseudo MAC addresses allows switches to forward traffic towards the appropriate pod or region of the data center, simply based on the structure of the MAC address. Now, because each host has a custom pseudo MAC address, it depends on its location in the topology rather than on its physical interface. We need a way of intercepting packets from the host and rewriting the MAC addresses for those packets. We also need a way of resolving ARP queries properly. These problems are solved by the fabric manager. Let's take a quick look at how the fabric manager solves both MAC learning and resolution of ARP requests. When a switch in the PortLand architecture sees a frame with a new source MAC address, it forwards that frame to the fabric manager. Which creates a new mapping between the IP address for that server and a pseudo MAC address that is assigned based on the server's location in the topology. Once that server has a pseudo MAC address assignment, of course, other servers in the data center need to learn about that server's pseudo MAC address through ARP. This creates a second job for the fabric manager, which is to intercept ARP queries and respond to the ARP queries with the appropriate pseudo MAC address for each host. When a host issues an ARP query to learn the MAC address for a particular IP address, the edge switch intercepts the ARP query, and redirects that ARP query to the fabric manager. Note the similarities in this architecture to conventional SDM designs, where a switch would redirect packets to an SDM controller. Upon receiving that query, the fabric manager would consult its pseudo MAC mapping table, and return the appropriate pseudo MAC address for that IP address, to the edge switch. The edge switch then creates the ARP reply, which it returns to the server. Finally, the host sends the ethernet frame to the pseudo MAC address, instead of to the actual physical MAC address. And switches in the data center's topology can then forward the frame along the appropriate path based on the hierarchical structure of the pseudo MAC address. In summary, data center networks have unique requirements for both scaling and flexibility. Data center networks have tens of thousands of servers, a need for minimal configuration and state, and the ability to quickly migrate virtual machines. PortLand's Fabric Manager is a very early SDN controller that solved many of the problems needed to scale a large layer two fabric for a data center network architecture. We looked at two aspects of the PortLand design that foreshadowed later SDN style control. These two functions were the assignments of pseudo MAC address and the ability to intercept and proxy ARP queries. PortLand's architecture, of course, has many other aspects that go beyond SDN. We have focused here on the specific aspects of the architecture that deal with SDN. If you're interested in reading more about the PortLand Data Center network architecture, we have provided a link to the paper on the course website.
