Welcome back. We are continuing our module on programming SDNs, and we are now starting a lesson on composing SDN control. This lesson will have two parts. The first part of the lesson will talk about the concepts of composing SDN control. The second part of the lesson will dive into a programing language called Pyretic which allows a programmer to compose SDN control. Networks perform many tasks. And if we think about how we might write an application that sits on top of an SDM controller that performs the wide variety of network tasks that an operator might want to perform, we might first consider writing a single monolithic application that performs all of those functions together. For example, the application might monitor or count the traffic volumes for particular traffic flows. It might route the traffic to different locations. It might apply firewalling policies. And it might also try to load balance the traffic across different servers. Now, the problem with a single monolithic application like this is it becomes very hard to program, test, debug, reuse, and port. Imagine, for example, that we wanted to test a certain component or reuse a particular component from this application. Well, suddenly we have a very big control program that is relatively unmanageable. A solution to this problem is to modularize the control so that the programmer writes separate modules, each of which performs a distinct operation. So, the operator might write a module that performs monitoring that is separate from the module that performs routing, firewalling, and so forth. This is much easier to program, test, and debug. And it's also easier for a programmer to reuse or port different components of this control application. However, getting the modules to play nice with one another is complicated. The controller has to perform some amount of arbitration among these modules because they're not just tenants that reside on the same control platform. In a multitenant environment, each module would control a different portion of the traffic guaranteeing that they wouldn't interfere. So, it would be relatively easy to partition the rule space, link bandwidth, and various network events across these different modules. However, in a control program, such as the one that we are talking about, different modules affect the same traffic. For example, the same traffic that's being monitored is also subjected to the routing, firewalling, and load balancing policies. So, each of these modules partially specifies how to handle traffic. And yet, these modules need to be combined, somehow, into a single complete control application that correctly implements the network operator's intended policy. The approach to this problem is to apply what is called composition. There are two types of composition operators. One is parallel composition where the control module performs multiple operations simultaneously. For example, the operator might want the control program to perform counting and forwarding on the same traffic stream. The second type of composition is called sequential composition. In this case, we perform one operation and then the next. For example, the network operator might want to first apply firewalling rules to the set of traffic before sending in the traffic through a learning switch. Let's now look at some example applications that use both parallel composition and sequential composition. Let's first have a look at parallel composition. Suppose that we would like to write a control program that both monitors traffic arriving on a particular source IP address and routes the traffic to different output ports depending on the value of the destination IP address. Now, in this case, we want both of these operations to happen at the same time. So, we apply parallel composition which produces a set of rules that effectively allows both of these operations to occur simultaneously. Note that, with this paradigm, we do not have to worry about which OpenFlow rules to install first. The controller platform automatically takes care of that for us. Let's now take a look at an example application that requires sequential composition. Suppose that we would like to implement a server load balancer whereby the load balancer spreads client traffic across multiple server replicas. There may be a public IP address for the service, for example, in this case 1.2.3.4, to which clients send their traffic. That load balancer then splits the traffic based on the client's source IP address and then rewrites the destination server IP address based on the client's IP. After rewriting the server's IP address, the load balancer then routes the traffic to the appropriate replica. This application requires what is known as sequential composition. First, we need to perform the load balancing operations of matching on a particular source IP address and, subsequently, rewriting the destination IP address accordingly, and then forwarding the traffic to the appropriate output port. As before, the controller composes these rules into a single set of rules that can be installed in the switches. Traffic can also be divided over modules. We can use certain predicates to specify which traffic traverses which modules based on both the input port and other fields in the packet header. For example, we can use a predicate to specify that if the destination port is not port 80, then we would like to perform monitoring and routing in parallel. But if the destination port is port 80, we'd like to perform load balancing followed by routing. Note that each module only partially specifies what should happen to traffic, leaving some flexibility to other modules. This avoids tying a particular module to a specific setting, thus making the modules more self-contained and portable. For example, when we applied load balancing followed by routing, the load balancer did not need to know how routing was being performed in that network. Therefore, if we wanted to use the load balancer in a different network, it would be relatively easy to reuse that component, even in a network where routing was performed in a completely different way. Another important feature of policy composition is that each module should have an abstract view of the topology. This abstract topology can implicitly encode constraints. For example, if the policy is intended to prevent two hosts from communicating with one another, we simply ensure that the logical typology has no path between those two hosts. The logical typology looks just like a normal network. But it prevents each module from overstepping or performing actions on parts of the network over which it has no purview. In other words, the logical typology hides irrelevant details from the modules. So, for example, the load balancer would not see such details as the internal topology, or any routing changes, or any routing changes. In summary, SDN control programs perform many tasks on the same traffic. The requirements for composing SDN control are compositional operators that specify how to compose policies and a logical switch abstraction that hides irrelevant details from each of these modules. In the next part of the lesson, we will look at a language called Pyretic that is built on POX. Pyretic implements both compositional operators and a logical switch abstraction.
