SDN in the Cloud.

Software defined networking is about refactoring the network control plane into a set of uniform abstractions that allow modularity resulting in a separation of concerns of the various demands upon the network.   The network data plane is already in place with a well-defined set of abstractions that are defined by the standard protocols that tell us how to use the local state and packet header to forward the packet. The abstractions needed by the control plane must provide a way compute the local state of the network in a way that it may be programed by a user in terms of topology and policy requirements and not specific distributed protocols and vendor specific mechanisms.

Scott Shenker, in his excellent lectures  states that the important abstractions include a general forwarding model, network state and simple configuration. OpenFlow is a good proposal for a forwarding API, though it is not the only one.   It allows forwarding to be described in terms of a table of <header, action> tuples.

The abstractions for describing and managing network state are critical. One problem with the current network stack is so many of the protocols are defined by complex distributed algorithms. All of these distributed algorithms must work together and proving things about their global properties can be very be very complex.   The SDN approach is to define a global network view API and allow all the lower level switches and other elements to be defined by this view. The implementation of this abstraction is through a “Network Operating System” (NOS) that runs in the hosts on the network. However, the network manager that specifies the operation requirements of the network such as access control, QOS, isolation need only described this in terms of a higher level abstract network view of a virtual network. As Shenker argues, a control program defined in terms of the requirements of the virtual network can be compiled into a graph algorithm written using the NOS APIs. This compiled program is basically a graph algorithm that operates on the global network view. The NOS implements this in terms of underlying switches and routing tables running in the host machines.

The control program can specify the topology of the virtual network, the access control policies and broadcast domains. The “killer app” for SDN in the cloud is the ability of a cloud customer to easy describe the extension of their “on premise” network into the cloud.   The customer can define all the access policies, the extension of the naming space and more. Even the needed load balancers are managed in the cloud servers so that hardware load balancers are no longer needed. This is all now standard practice in the large public cloud space.   Albert Greenberg has brilliantly described this in his lectures and the software defined network that makes Microsoft Azure work.  Greenberg states “Windows Azure supports virtual networks, rich load balancing, tenant ACLs, and more for hundreds of thousands of servers, via software: No Hardware per tenant ACLs, No Hardware NAT, No Hardware VPN / overlay, No Vendor specific control, management or data plane, All policy is in software and everything’s a VM! “ These Azure customer can build the network control program by simple options available on the Azure portal.

The statement that the abstract network can “be programmed” is not just a metaphor. The work by Joshua Reich, Christopher Monsanto, Nate Foster, Jennifer Rexford and David Walker on the programming language Pyretic  is a great example.   The result is a functional-style Python variation that encourages a “policies as abstract functions” approach to specifying the network behavior.