Software Defined Networking (SDN) is an easy to grasp, transformative concept with complex, diverse implementation options which this blog will explore from web research listed in the bibliography as of its writing Jan 2018.
SDN is still evolving based on work at several standards bodies. The Open Networking Foundation was founded in 2011 to promote SDN/OpenFlow and the Linux Foundation announced in April 2013 the OpenDaylight Project (ODL) and later ONOS in 2015.
Here is the Wikipedia list of open source SDN initiatives:
• Open Daylight (controller baseline upon which other controllers are built)
• Project Calico
• The Fast Data Project
• Project Floodlight
• Open vSwitch
• vneio/sdnc (SDN Controller from vne.io)
• Ryu Controller (supported by NTT Labs)
• Faucet (Python based on Ryu for production networks)
Please see Part 1 of this Blog for a review of NFV.
The first time I heard the phrase “network operating system” was in the early 1980s regarding Novell Netware or Banyan VINES products that allowed shared file and printer access among multiple computers over a LAN along with other centralized networking functions in a client server architecture. These functions have since been subsumed by server operating systems like Windows Server. But many of the concepts of SDN date back to this period where separating the control and forwarding planes was discussed in SS7 networks, IP switching, and ATM networks.
In the mid-1990s as Internet usage started to explode, the precursor research work for programmable networking that eventually led to SDN was called Active Network which was funded by USA/DARPA up into the early 2000s (DARPA had previously funded the development of the Internet.) The motivation for research in Active Networks was, like it is still today for SDN, a desire to: reduce the time needed to deploy new services, leverage the reduced cost of computing (and now cloud computing) to reduce OPEX, and better network management with unified control over networks that were becoming more cumbersome with the proliferation of vendor specific network nodes including firewalls, proxies, policy servers, and transcoders.
As I heard it or read it – but I can’t source it, a research project, the Clean Slate Program, was started at Stanford University mid-2000s to answer the question what would we do differently if we were able to redesign the Internet from a clean design sheet. The answer was to separate the management and control planes from the data plane in routers. (Router tables that only list choices for the next hop are problematic from a network assurance perspective because re-routed traffic can flood the re-route link – so, an abstracted global, view of the network was needed to efficiently re-route traffic.)
In any case from a historical perspective, in about 2008 and previously in 2006 as the SANE project; the “Programmable Open Mobile Internet 2020 (POMI) project” was funded by the National Science Foundation at Stanford University and University of California Berkeley with the objective of defining a standard for software-defined networking (SDN) as a way of configuring network routing and network addresses through software. That standard became OpenFlow and its appeal took off like a rocket because of its adoption by virtually all network equipment manufactures and standards bodies. It was followed quickly by the design of an SDN controller platform, NOX, by Nicira Networks and later BEACON in 2010 all of which were donated as Open Source in 2008. Nicira was subsequently acquired by VMware in 2012
The most relevant developments occurred around 2015 when it was finally determined which layers comprise the SDN architecture and which interfaces are best suited for interoperation between them.
See Figure 1 showing SDN as layered architecture.
NOTES for Figure 1 – SDN Terminology and Popular Products:
1. A “plane” distinguishes between different areas of operations versus a layer of software. The planes can be moved around within the SDN architecture e.g. the control plane can be depicted as a service to a management plane when placed above the control plane.
2. The “Y” in the figure denotes an interface.
3. Examples of forwarding-plane abstraction models are the Forwarding and Control Element Separation (ForCES), OpenFlow, YANG model, and SNMP MIBs.
4. Examples of the operational-plane abstraction model include the ForCES model, the YANG model, and SNMP MIBs.
5. Communication between control-plane entities is usually implemented through gateway protocols such as BGP or other protocols such as the Path Computation Element (PCE) Communication Protocol (PCEP). Other examples are SoftRouter, and RouteFlow.
6. Examples of CPSIs are ForCES and the OpenFlow protocol.
7. Examples of MPSIs are ForCES, NETCONF, IP Flow Information Export, Open vSwitch Database (OVSDB), and SNMP.
SDN Platforms as Network Operating Systems
Software Defined Networking (SDN) can be considered as a “network operating system” in that network intelligence is centrally managed (logically) by maintaining an abstracted global view of the network– essentially a programmable router/switch model for physical or virtual networks.
In contrast to earlier research on active networks that proposed a node operating system, a network operating system is software that abstracts the installation of state in network switches from the logic and applications that control the behavior of the network leading to the conceptual decomposition of network operations into layers.
The OpenFlow model is the model that I had in mind when researching for this blog, but it quickly got more complicated. Nowadays there are typically at least two sets of SDN controllers:
• SDN controllers for the NFV infrastructure of a datacenter,
• Historical SDN controllers for managing the programmable switches of a network.
OpenFlow is merely one widely popular instantiation of SDN principles. Different APIs could be used to control network-wide forwarding behavior; previous work that focused on routing using BGP as an API could be considered another instantiation of SDN, for example architectures from various vendors e.g. Cisco ONE and JunOS SDK represent other instantiations of SDN that differ from OpenFlow.
Adoption of SDN by the Communications Industry – Cloud & Virtualization as a Use Case for SDN
Implementation of SDN by network operators for cloud based network operations was slower than for premise or cloud based datacenters because network operators required significant organizational and skill transformation to demolish network/vendor silos and there was a lack of comprehensive and performant NFV/SDN solutions that met “carrier grade” requirements. IT datacenters with vast arrays of server farms were quicker to grasp the benefits of SDN (and cloud computing)
Since then, the pace of NFV/SDN adoption still has not yet matched the early vision although progress has been made by Tier1 operators (AT&T, Verizon, NTT, China Mobile, Telefonica, etc.) for services like: Evolved Packet Core, virtual Customer Premise Equipment, vVPN, and IP Multimedia Subsystem. It remains to be seen if the rest of the industry will be fast followers.
Telco hybrid clouds combining public and private cloud computing as part of the upcoming 5G ERA is probably the biggest driver for SDN & NFV versus the other way around. I heard that every 5G slice will require its own SDN controller. In the case of SDN controllers for the NFV infrastructure, NFVi including SDN represents only about 15% of the spend for cloud based VNF/NFV/MANO/OSS software products estimated by Ovum to be $34B in 2022.
For NFVi, SDN is mostly designed to provide policy and centralized management for the Openstack/Neutron networking layer that provides inter-working between the virtual ports created by Openstack/Nova. Technically, the defacto technology of these SDN controllers is to manage the Linux kernel features made of L3 IP routing, Linux bridges, iptables or ebtables, network namespaces and Open vSwitch.
Hyperscale players like Google, Microsoft, and Amazon that have been cloud based from the start continue to lead in this regard. (The Google WAN Controller B4 project for their datacenters which may have been co-developed with NTT was one of the first commercial SDN deployments starting in 2012 implementing OpenFlow/OVS/OVSDB-ONIX for Linux based hypervisors.)
The path for network operators probably remains long for most network operators but automating the lower part of the stack, the NFVi, which includes SDN represents an early, useful win. While early SDN deployments focused on university campuses, data centers, and private backbones, recent work explores applications and extensions of SDN to a broader range of network settings, including: home networks, enterprise networks, Internet exchange points, cellular core networks, cellular and Wi-Fi radio access networks, and joint management of end-host applications and the network.
Three Illustrative Deployments
NTT Com’s SD-WAN
NTT Communications Corporation (NTT Com) offers a software-defined wide area network (SD-WAN) Service Platform, which covers more than 190 countries. SDN and SD-WAN are closely related as both are software-defined – SDN is an architecture whereas SD-WAN is a purchasable technology based on that architecture. NTT SD-WAN real-time streaming sheds light on application performance, network security and customer experience. NTT Com uses its SD-WAN to scale operations and to bring new services to the market swiftly
Microsoft’s virtual machine manager
Microsoft’s virtual machine manager (VMM) can deploy and manage software-defined infrastructure. It is used to configure conventional data centers and provide a unified management experience. Among its competencies, VMM provides virtualized hosts, network and library resources, and allocated storage.
When SDN is woven into the VMM tapestry, users can perform a variety of tasks. These include overseeing the infrastructure, like network controllers, software load balances and gateways; defining and managing virtual network policies; and directing traffic flows between virtual networks. Furthermore, it integrates numerous technologies, such as the network controller, RAS gateway and software load balancing.
Tribune Media had arguably the biggest SDN deployment using VMware NSX, which transferred more than 141 applications to an SDN infrastructure over five months. Tribune Media cut ties with the rest of the Tribune Company in 2012. As a result, the company had to replace its IT infrastructure and applications. Consequently, Tribune Media chose VMware SDDC as the foundation for its IT infrastructure.
Although a significant topic, SDN storage is beyond the scope of this blog