The evolution of SDN

My post today is largely extracted from a talk that Scott Shenker (A professor at Berkley) gave at Stanford last year. I’m going to paraphrase what I got from the talk.

Many people have asked me to describe SDN and why we need it. It is not obvious to  networking professionals that the current Internet has a problem that needs to be solved. During the talk Scott uses a quote from another professor to sum up the problem.

“Modularity based on abstraction is the way we get things done.” – Liskov

The networks that we have today really have two primary functions which provide two opportunities for abstraction (Control and Data). The Internet has done an excellent job of abstracting the data plane by providing reliable transport, best effort global and local packet delivery and the local delivery of bits.

The Control plane is a different story in that it is a collection of protocols with little to no abstraction. Everything in the data plane happens in nano-second time slots while things in the control plane happen in millisecond or greater slices.

Because of the fundamental differences between these two things, they define a logical place for abstraction.

“The problem that SDN set out to solve is that the control plane has no abstraction and without abstraction, things are difficult to manage, evolve and understand.”

The first pass at defining SDN resulted in three levels of abstraction. The first level was the control program, then the global network view and finally the NetworkOS(NOS). This has evolved to the control program, the virtual topology, the network hypervisor, the global network view and the NOS.

The control program is responsible for the collection of information from the network operators. This would include things like connectivity, isolation and access control. These rules are expressed on the virtual network topology which is a simplified version of the global network topology.

The network hypervisor is responsible for translating the rules defined on the simplified virtual network topology into rules that can be applied to the real global topology. This would be done by a compiler of some kind and will be complex. The network hypervisor is  responsible for monitoring global topology changes and re-applying the rules as required.

The NOS is responsible for delivering rules to the individual network elements.

You could argue that the network topology is not likely to change, but when you consider potential differences between edge and core network functionality, it becomes obvious that future networks will be much more dynamic.

Lets consider future networks and the separation of core and edge functionality.

One of the things that the original definition of SDN got wrong was that all switches were homogenous in role/function. In actual fact there are three basic things that happen at the switch level.

  1.  Hosts send packets to the network with an origination address, destination address and potentially a QOS.
  2.  Routers peak into the packet headers and forward the packets along the way and
  3.  Operators provide traffic engineering, isolation and access control rules to alter the flow.

Switches today group 1 and 2 together and provide no interface to handle item 3. The initial definition of SDN provided and interface for item 3, but still grouped 1 and 2 together. The latest definition for SDN uses MPLS to separate functions 1 and 2.

What this means is that the edge switches apply MPLS tags and the core switches use the tags to forward traffic while SDN provides the operator interface. This means that the core now has only one job to do and that impacts things like link failure recovery. Core link failures will recover in nano-seconds instead of milli-seconds.

You could argue that the MTBF for core switches is so high that failures will be rare. If we consider cloud based segments of the network however, we find that this portion of the network is in constant flux. VM’s move between compute nodes and systems like OpenStack can move VM’s based on load. As clouds grow, the network will become increasingly dynamic.

Another of the original assumptions of SDN was that all switches would be implemented in hardware and that has proven to be completely wrong. In 2012 the number of software ports exceeded the number of hardware ports in the Internet by a significant margin. In that same time period, Intel cores improved their ability to route packets resulting in through puts like 23.5 Mpps per core.

If you consider this number for a moment and apply it to inter-domain traffic between some of the biggest service providers, $150,000 of Intel cores could handle all inter-domain traffic. This is a fraction of the cost of a hardware router.

Hardware routing is still faster, but software routing at the edge is fast enough.

“By tagging packets at the edge of SDN networks, the core becomes protocol agnostic!”

Scott points out that by giving the core one job to do,  means that changes like moving from IPV4 to IPV6 become edge problems. This adds flexibility for future changes.

Another of the other initial assumptions that was made when SDN was defined, is that the data plane is simple. The data plane actually contains a number of middle-boxes that implement functions like firewalls, WAN optimization, Proxies, Gateways, VPN’s, load balancers and Intrusion detection. Surveys have shown that the number of middle boxes actually increases proportionally with the size of the network.

Most packets are touched by middle boxes, but that happens primarily at the edge of the network. Interestingly, most of the middle boxes contain software that runs on x86 processors. Virtualizing middle box functionality and placing it at the edge, supports the premise that the edge and core of the networks function differently and is one of the things that NFV addresses.

In summary then:

  •  SDN established Control Plane modularity.
  •  Network Virtualization decoupled the control program from the physical network
  •  Edge-Core distinction moves functionality to the edge.
  •  Software at the edge removes functionality from ASIC’s and hardware.
  •  Software forwarding will get faster with time
  •  Software is more flexible and provides a platform for innovation.
  • X86 hardware will continue to improve and provide COTS savings.

SDN and NFV will provide faster innovation, more competition and a better customer experience.


This entry was posted in Uncategorized and tagged , , , , . Bookmark the permalink.

One Response to The evolution of SDN

  1. Peter Haighton says:

    Hi Fred,

    From my reading it appears that the network itself becomes protocol agnostic since ipv4 and ipv6 are moved to the edge. This sounds very similar to frame relay, in that the network does not care about the ip packet routing information, it wraps it into its data structure.

    I am not sure however how from the information how control can change from milliseconds to microseconds, since there has to be time to determine that a router has stopped functioning.

Leave a Reply

Your email address will not be published. Required fields are marked *