Introduction to SDN
(This entry is scheduled to be published on our corporate newsletter, the Datatrend Insider. A link will be added here when it is published)
As a new and emerging technology, Software Defined Networking (SDN) is somewhat difficult to define. Ask 10 different people what SDN means, and you are likely to receive 10 different answers. (Does this remind you of the term “Cloud” in its early days?)
There are a couple of standards groups that are quite heavily entrenched in the world of SDN; the Open Network Foundation (ONF), and the OpenDaylight Project (link). ONF defines Software Defined Networking as “The physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices” (link). The OpenDaylight Project defines SDN in a similar manner; “Software Defined Networking (SDN) separates the control plane from the data plane within the network, allowing the intelligence and state of the network to be managed centrally while abstracting the complexity of the underlying physical network.” (link)
To illustrate this concept , an Ethernet switch (the IBM G8264 is pictured here) can be described as three functional parts;
First, processes within the switch decide what to do with each individual packet as it arrives on a port. Should the packet be forwarded? If so, should it be flooded to all ports? Is there an entry in the forwarding database and therefore only forward the packet out a specific port? This function is called the “Control Plane” (or the “brains” of the device).
Second, the device contains the electronic circuitry to actually perform the sending and receiving of packets. This function is called the “Data Plane” (or the “muscles” of the device).
There are also management processes in the device used to configure the switch, send SNMP alerts, manage the boot-up and operating system, and so forth. Although not always depicted, this is referred to as the “Management Plane” (or the “secretary”.)
In the ONF definition of SDN, the data plane (packet forwarding) and management plane stay with the device. The control plane (forwarding decisions) is consolidated in a central location. This central “brain” is the OpenFlow Controller. It takes the information about packets arriving at the physical switch port and makes a decision as to how to process the packet. This decision is made based on the first packet and then the controller programs all of the open flow switches in the path with the forwarding information.
Generally, there are two recognized models for Software Defined Networking;
The OpenFlow Model, and Network Virtualization.
OpenFlow is an open standards protocol maintained by the Open Networking Foundation (ONF). The OpenFlow protocol uses a software program called a controller to configure the data planes on the devices it controls. As a work in progress there are multiple versions of this standard; Be sure you know what the hardware supports.
There are many controllers available in the open source world including the OpenDaylight controller and “Floodlight” from Bigswitch amongst many others.
Commercial controllers are also available from the major network vendors. Cisco offers the XNC controller, Cisco OnePK and its latest entry, Application Policy Infrastructure Controller (APIC) that came with the recent Insieme announcements. IBM offers the Programmable Network Controller (PNC) and VMware launched its NSX solution earlier this year and it is based on its Nicira acquisition earlier in 2013.
For the data plane perspective, many switch vendors now offer OpenFlow support on their devices. All of IBM’s Top-of-Rack switches and the EN4093 Flex System switch offer OpenFlow support. Cisco Nexus 3000, Juniper, Brocade and HP also offer OpenFlow support on many of their hardware switches.
The other model for SDN falls under the umbrella of Network Virtualization. This term commonly refers to hypervisor environments. VMware Distributed Virtual switch and 3rd-party replacement products, like the Cisco Nexus 1000v, the IBM DVS 5000v, virtual routers, firewalls, etc. In this type of deployment, the control plane is generally deployed as a virtual machine, and the data plane is a module loaded onto each hypervisor host.
When VMware acquired Nicera in 2013, the Network Virtualization Platform (NVP) was rolled into the latest vSphere offering; NSX. VMware NSX includes the ability to deploy distributed switches, routers, firewall rules and load balancing functionality within the vSphere environment.
Traditional hardware appliances are also virtualized; F5 Application Delivery Controllers are offered as virtual images and other vendors also offer virtual versions of typical networking appliances.
By deploying the network devices and services as part of the virtualization platform, networking can be as robust and agile as software applications in a virtual deployment.
How is SDN deployed?
A Software Defined Network can be used as part of a larger data center orchestration application. As new applications or services are deployed the network devices can also be configured as needed for the application.
Northbound and Southbound APIs
Application Programming Interfaces (APIs) are used to allow one software program to control another software program. In the world of SDN, typically, two different classes of APIs are defined: Northbound and Southbound.
Southbound APIs are used from the controller down (south) to the controlled device. For example, OpenFlow is considered a Southbound API, as it is the programming interface that the OpenFlow Controller uses to program the forwarding tables of the OpenFlow device. Another example of a Southbound interfaces is Cisco’s OnePK.
Northbound APIs are used to program the Controller from a higher-level business intelligence application. For example, OpenStack includes a module called “neutron” (originally called Quantum) which can be used to provision network services as virtual machines are simultaneously provisioned in the cloud. Most of the SDN applications available today offer a RESTful (REpresentation State Transfer) API, which can be easily called from and manipulated from many programming languages, including python and html.
The OpenDaylight Project uses this architectural model to depict how the various pieces of a SDN solution can come together to create a multi-vendor, multi-product solution.
Now that we have networking services controlled by software processes, whether they are hardware or software based, what are some of the things that can be done with this new and emerging deployment methodology?
Responding to relocation of virtual machine (vMotion)
As virtual machines are relocated throughout the cloud, the Virtual Machine Manager controls the movements. In the traditional networking paradigm the physical hardware is not aware of the relocation of the workload, therefore, many things have become potential problems in the data center.
When the VM was originally deployed, the network flow from point to point was known, and the firewall, load-balancer, and routers positions in the network made sense.
As a result of an unplanned outage, or during a maintenance action, the virtual machines are usually relocated to a different host (or set of hosts) while the original host is out of service. As the VMs were spread around the network, the traffic patterns became less efficient, leading to what is called “traffic tromboning.”
If the network functions were virtual in nature, or if the network was also made aware of the changes in workload traffic patterns, the network itself can respond to the changes by either relocating the virtualized services to fit with the new virtual machine placement or change the path the traffic flows through the network to better optimize the network traffic.
Virtual Tenant Networks (Network Slicing)
Another key benefit of SDN is in the realm of traffic separation. With SDN it is much simpler to maintain traffic separation between applications or between different customers within the virtual environment. This is called “Network Slicing” or “Multi-tenancy.”
Service Insertion/Service Chaining
With a SDN it is possible to add or remove network services in the path of applications and their supporting VMs.
With SDN it is possible to define a specific path for each type of traffic. This allows for what is called “Services Chaining” and “Service Insertion.”
Alternately, it is possible to copy all traffic traversing the network, and send it to the security apparatus. This concept is sometimes referred to as a “network tap.”
Responding to a security threat
With the use case of network tap it is possible for a security device to capture a copy of all network traffic and, if an anomaly is detected (virus, network attack, etc.), the security appliance could submit a flow change to the controller, and send the suspect traffic to an IDS/IPS cluster, through a firewall, or send the traffic to the “bit bucket” (drop the traffic.) Once the threat is abated the security appliance could ask the flow be removed from the flow tables or set a new firewall rule to block any further activity from the threat.
What are some of the benefits of SDN?
There are potentially many benefits to the Software Defined Networking model(s), including:
Speed and agility in provisioning network services.
SDN provides the ability to quickly and programmatically provision network resources as part of a higher-level orchestration platform. As workloads are deployed and retired the required network services and components can be provisioned as part of the workload.
Holistic view of network traffic
With a centralized view of network traffic within an SDN, the controller is able to detect issues in one part of the network that may affect another part of the network and take appropriate action to mitigate the issue.
With a centralized view, and improved agility within the network, businesses and network operators are better able to deliver the network services required for a multitude of different applications and workloads.
While showing great potential, SDN is not without its share of concerns. The newness of the technology is the primary concern for many who look at SDN as their network operational model. Standards are still evolving and vendors are working to carve out a place within the market. If you jump in too soon with the wrong solution, you may end up having to start over.
Security is also a potential concern. As a new and emerging technology it is not yet known what security exposures your security strategy must account for.
Additionally, network administrators will need to learn new and different ways of thinking about, designing and operating within this new networking paradigm.
How to begin working with SDN Solutions
SDN does not require a wholesale “rip and replace” strategy to get started.
Many network devices can operate in “mixed” mode where some portion of the device operates in a traditional fashion and other portions of the device can be controlled by an OpenFlow controller. Almost all network hardware appliance vendors offer a virtual appliance version of their product.
Where might SDN deployments be appropriate? If you’re thinking of setting up a private cloud for a department or a given set of development projects, that may represent an excellent opportunity to pilot some of these technologies.
If you are in the process of planning a major restructuring of your network, some portion of it, or planning for the rollout of a new application or service, it may make sense to take a look at SDN as a potential helpful technology with an eye to integrating more SDN services as it moves forward
While still an immature technology, SDN represents the future of networking. All of the major network vendors have products available and a roadmap to bring forward more offerings. There are a number of startups that are trying to make their way into the market and standards are evolving. It will also take some time for network administrators to learn new skills and processes. Software Defined Networking will be the next major wave of network technology.