Welcome back. We are continuing our discussion of SDN deployments in the wild, in wide area backbone networks. In this lesson, we will be looking at B4, a deployment of software defined networking in a wide area backbone network at Google. Google operates two large backbone networks. One is the backbone network that carries user traffic. The other is the backbone network that carries internal traffic or traffic between data centers. Managing both of these backbone networks is difficult, for a variety of reasons that we'll talk about. SDN, and in particular OpenFlow, has helped Google improve backbone network performance and reduce the complexity and costs of running their data center backbone network. More details of what we'll talk about in this lesson are available at the URL on this slide. Which contains a presentation that discusses Google's SDM backbone at the open network Summit from April 2012. Google runs many different WAN-intensive applications, ranging from YouTube, to web search, to photo sharing and hangouts, to maps, to AppEngine, to software updates for Android and Chrome. The problem with running a lot of these WAN-intensive applications, is that the cost per bit does not necessarily decrease as the size of the network increases. As network size increases, the complexity of pairwise interaction between network devices, the manual management and configuration of the network. And having to deal with nonstandard vendor APIs from many different network devices and become incredibly challenging and costly. The solution that Google has chosen to employ is what they call WAN fabrics. The idea is to manage the wide-area network as a fabric. Not as a collection of individual boxes. Unfortunately, current equipment and protocols make this particularly challenging. Many network protocols today are box-centric. They provide very little support for monitoring, low-latency routing, fast failover, and other types of mechanisms. That are needed to provide this fabric abstraction. Let's consider an example of what happens to routing convergence when a failure occurs. Let's suppose that initially, we have three flows, one from R1 to R6, one from R2 to R6, and one from R4 to R6. Each of these flows carries 20 units of traffic, but links in this topology are annotated with the respective capacities. Let's suppose now that a link fails, such as the primary link between R5 and R6. In the conventional case where distributed routing protocols must find a new working path to R6. Each of these nodes must iterate through a number of possible alternate solutions, before arriving at a new set of paths that satisfy the capacity constraints. In this trial convergence, R1 succeeds in finding a new path to R6. Through the bottom link that has capacity 20, however, R2 and R4 also try to use the same link and encounter congestion, because R1 has already fully occupied that link. R2 and R4 must then iterate until they find new working paths to R6. This process, whereby each node independently searches for a new working path, can be particularly slow as each iteration may induce new conflicts among alternate routes. In contrast, one might use a centralized traffic engineering approach, whereby a centralized controller simply allocates the paths between each pair of endpoints to satisfy the capacity constraints of the network. The advantages of centralized traffic engineering are better network utilization, since the controller has a global picture of the topology. Faster convergence to a target optimal set of routes when a link fails. More control and the ability to specify intent, for example the ability to specify deterministic behavior, rather than having to over-provision to take into account the possible worst case. The ability to mirror production event streams for testing, and the ability to use modern server hardware for the controller, which results in about a factor of 50 performance improvement. The deployment of SDN in the wide area network can also help testing. In a decentralized network, operators must implement a full scale replica, testbed to test new traffic engineering features. This is because it's very difficult to figure out what effects the configuration change might have on a set of contributing routers. In contrast, centralized control can use a real production network as the input to research and test new ideas and features. The control servers can run real binaries, but the switches representing the emulated network can be virtualized. Note that this approach which Google uses for testing its control framework, is exactly what you're doing in the assignments using Mininet. Your controllers are real. Even know the network that you're testing on is emulated in Mininet. In summary, a software defined wide area network separates hardware from software. It allows operators to choose hardware based on the features that they need. And choose software based on the requirements of protocols that they need to run the network. Logically centralized network control for traffic engineering allows for easier management and easier testing. Finally, a software defines WAN can allow operators to separate mentoring management and operation. From the individual boxes, that now only need to forward the traffic based on the decisions of the controller.
