.shock - Fotolia

As the 'brains' of SDN, network controllers enable agility

Following the lead of hyperscale providers like Google and Amazon, IT managers employ software-defined network controllers to meet the requirements of monolithic applications.

The data center practices of hyperscale providers such as Google, Facebook and Amazon are prompting IT managers to evaluate which powerful scaling technologies they might be able to deploy within their own organizations. One such technology is software-defined networking. SDN allows hyperscale operators to change a network rapidly to meet the requirements of monolithic applications, such as search, and the public-facing cloud. So let's look at the role SDN and network virtualization can play in the enterprise data center.

SDN and its uses

Software-defined infrastructure components allow for the separation of the control plane from the data plane. In the case of SDN, that allows for the management and flow control of data. SDN protocols, most notably OpenFlow, enable the centralization of traffic management and flow.

The OpenFlow concept is simple, yet powerful. Network administrators use the idea of intent to dictate the flow of traffic. Instead of using quality-of-service rules and virtual routing and forwarding to control traffic based on IP source and destination, an administrator will configure traffic flow based on application traffic.

An example of this would be creating an OpenFlow policy that prioritizes and routes virtual desktop traffic through a dedicated Multiprotocol Label Switching connection during peak demand. When peak demand ends, virtual desktop traffic is routed over a VPN.

Another use case for Software-defined networking is service provisioning and device configuration. One of the major aggravations in implementing cloud computing is the automation of device state configuration. It's worth taking the time to examine the workflow for network provisioning in a typical cloud use case.

If a developer wants to provision a standard three-tier application using a self-service portal, all or at least some of these network actions need to take place:

  • Configuration of Layer 2 virtual LANs;
  • IP address assignment;
  • Provisioning and configuration of an application load balancer;
  • Firewall configuration; and
  • Adjustment of routing policy based on an application's traffic priority.

For any decommissioning activity, these workflow steps would be reversed.

The initial difficulty in provisioning is the lack of consistent management APIs across network vendors. A secondary challenge is that network protocols don't lend themselves to this type of process automation. Lastly, the physical nature of network devices is out of step with the virtual workloads of cloud computing and the modern data center.

Cloud is just one example of where adopting SDN can enable agility in the data center. Companies have also used SDN to meet the requirements of enhanced application security and network management. The abstraction of the control plane is crucial to enabling enhanced network functionality. Network controllers provide the APIs for improved agility, flow control and security.

The network controller

Today's network controllers have advanced well beyond OpenFlow traffic-management tools. Network controllers can rightly be considered the brain and central nervous system for any SDN technology.

Using north and south APIs, SDN controllers enable control of the network via application interfaces such as cloud management platforms (CMP) or network policy engines.

Since they provide the network with an API, network controllers allow for the orchestration of the tasks needed to provision the network in our earlier cloud example. The CMP will make requests to the network controller to perform each of the required tasks. The network controller would then leverage the southbound APIs to provision the underlying network as needed. Next, the underlying network would use northbound APIs to report the status of each task and the current state of the network.

Established networking vendors and several network startups have introduced full-featured network controllers which are primarily software platforms. Like all modern software, controllers come in two different flavors: open source and closed source. The open source project OpenDayLight (ODL) powers many of the open source controllers on the market. Vendors such as Brocade have based their network controllers entirely on ODL.

The primary advantage of building network controllers on OpenDayLight is interoperability. Since ODL is an open source platform, organizations can extend its capabilities to support their existing tools. Cisco's Application Centric Infrastructure product is a closed source network controller. For interoperability with Cisco-based networks, Cisco provides plug-in integration for ODL controllers.

Because ODL is a young project, we're unlikely to see nonbranded ODL systems in production. Companies such as Brocade offer a fully supported distribution that has heavy integration with Brocade-branded hardware.

On the closed source side, vendors have a strong ecosystem with which to work. Products from vendors such as Cisco allow for tight integration between the application policy infrastructure controller and hardware platforms -- such as the Nexus 9000 -- and virtual platforms -- such as the Nexus 1000v. The close integration allows network managers to operate both the physical and virtual network as a single network.

Network controllers enable API-level interaction with the network. Network controllers leverage vendor-specific APIs to configure and manage the underlying network.

It's not difficult to picture the underlying network as physical resources managed by a network controller. The idea of a Brocade Vyatta Controller, configuring Cisco Adaptive Security Appliance firewall rules to allow Web traffic to a new application, is not a stretch of the imagination. You have a physical controller, which controls physical network security devices to allow traffic from a physical server, but this is no longer the landscape of the typical corporate network. At this point, the number of virtual network ports outnumbers the number of physical network ports. Just as with servers, the network has become virtualized.

In part two of this article, we'll dig into how network virtualization works and how it affects IT managers.

Next Steps

Understanding the relationship between SDN and network virtualization

A buyer's guide to data center switches

Up-and-coming alternatives to OpenDaylight

Comparison of OpenStack and OpenDaylight

Dig Deeper on Network virtualization