Virtualization killed the hardware business for companies like Sun (now Oracle). What virtualization did was make popular the idea of replacing physical servers with virtual ones. That drives down the price and increases standardization, which drives down operating costs. You can even see this in the name, as people call virtual servers “commodity hardware.” That means all of those expensive Solaris servers have been replaced with virtual servers running on high-end PCs. It also means that RISC and other processors have been replaced with the 8088-base CPUs, which are plentiful and inexpensive.
Therefore, management, who pays the bills, asks, “Why not do the same thing with networking?” They question, “Why does every network function need to have its own proprietary device? Why do we need one person to configure routers and another person to configure the firewall? Why can’t there be some open standards to make it easier to manage all this?”
That is what SDN does, or attempts to do. The idea is to use Linux servers and push networking functions onto those, for the control plane or even the data plane. The data plane, which is where the switches live, can be virtual or physical devices in the SDN model. By moving to virtual switches, a company can replace some of its Cisco, Palo Alto, F5, and Alcatel-Lucent equipment with something open and less expensive.
What’s needed to make all of this work are standards, and products built using those standards. Here we present some of those. First we’ll look at some open source products. Then we’ll look at some products that, while they are not open source, support open-sourced interfaces.
- Open vSwitch
OpenFlow is a standard for the interface between the control and forwarding layers in the SDN architecture. The forwarding later includes switches and routers, both physical and virtual; that could be the same as the data plane, depending on what definition you want to use. (To review, the definition of a router is that it has an internet connection. A switch connects two LAN segments. Each looks in their routing table to forward network traffic to its destination.)
Here is a graphic from the Open Networking Foundation to illustrate the SDN abstraction:
As you can see, OpenFlow sits between the control layer and the forwarding layer, which they call the Infrastructure Layer in this graphic. At the control layer, the devices are abstracted, meaning the specific implementation details are coded elsewhere. In this mode, if the device is physical and if the device vendor supports the OpenFlow standard, their physical device can be controlled from the control layer. The control plane is run on virtual machines. The switches can be physical devices or virtual ones. A physical switch might be needed when a Linux server cannot handle a large enough volume of traffic, because the physical device is built for that specific routing task. Yet some vendors are focusing on the problem of how to boost throughput from Linux servers to meet such switching demands.
xDPd (eXtensible OpenFlow Data Path daemon)
xDPd is an open source switch based on the OpenFlow standard. It has a control module, hardware abstraction layer, and platform driver. As you can see from the graphic below, the platform driver is a set of APIs that the hardware vendor would have to implement to make it work with this virtual switch. For example, to plug a Cisco switch into this model, Cisco would have to program to this API.
Open vSwitch says their solution solves the problems with the L2 bridge built into Linux that is designed to connect virtual machines to other networks, which they say does not scale. They say their open source product “is targeted at multi-server virtualization deployments, a landscape for which the previous stack is not well suited.”
The Open Networking Foundation lists some SDN products here. Below we take a look at a few.
The products are grouped into these categories: optical networking, APIs, application acceleration, switches, routers, network virtualization, WAN optimization controllers, network operating systems, security products, and firewalls.
All the products listed support OpenFlow. Some are SDN products, and the rest are physical hardware. As you will see, most of what the traditional network vendors are calling switches are not software-based switches running on Linux, but hypervisor-based control plane software. So there is some confusion about where to draw the border with the definition of SDN.
This one is a genuine software-based virtual switch running on Linux. 6Wind says their packet processing software provides a 10x boost to network performance over Linux-based VMs. This includes routing, IPsec VPN, NAT, firewall, TCP, and UDP. This is done by using Fast vNIC drivers.
Cisco Application Virtual Switch
The Cisco Application Virtual Switch is a hypervisor-based virtual switch.
Cisco does not want to get left out of the SDN market, but you could say that the very goal of SDN is to do just that. For many years Cisco has had almost a monopoly in the switch market, but not anymore. So SDN could be a threat to them if it gains traction among very large network operators.
Cisco Nexus 100c Switch for Microsoft Hyper-V
The Microsoft virtual machine operating system is called Hyper-V. It’s not clear how Cisco plans to make money from this, since the product is free. Except that it is designed to work with Cisco switching hardware, too.
Juniper Networks OCX1100
This is an open source hardware switch that uses the Open Compute Project (OCP) hardware design. Juniper says their product is optimized for the cloud. It is designed for large cloud service providers who are building virtual machines and storage per the OCP specifications. The switch uses the Junos operating system. To say that it is open yet uses the proprietary Juniper OS means that it can be driven from OpenFlow control plane software.
NEC ProgrammableFlow PF1000 Virtual Switch
NEC is another one of the big networking companies. This product provides a network control layer on Microsoft 2012 Hyper-V virtual machines. The PF1000 Virtual Switch sits between the hypervisors and the switch hardware. The focus here is on centralizing the provisioning of networks and services, or what they call “automation and control.” It also provides network monitoring.
What appears to missing from the effort to move networking to standards is standardization at the API level. In other words, OpenFlow includes specifications for packet forwarding. But there is no single set of commands for operations like add route, delete route, add firewall rule, set gateway, and so forth. Those details are implemented by each vendor.
But what you can definitely say is the SDN lets organizations run the control layer on virtualized servers. So companies can use those servers for orchestration, provisioning, monitoring, and control instead of buying more costly, proprietary equipment from Cisco and others.