Getting Started with Software-Defined Networks

Ask three network experts to explain software-defined networking (SDN) and you'll get five different answers. In concept, the goal of SDN is to free network control from a series of complicated, distributed protocols and establish a more centralized control system that simplifies configuration and reduces complexity. It does this by decoupling the data and control planes of a network.

In traditional networking, engineers talk about data and control planes as if they were separate things. The data plane, they say, is the part of the network that moves packets from one network port to another, either within a LAN (switching) or across networks (routing). The control plane tells the data plane how to switch or route the packets. The control plane in one system talks to the control plane in another system using very well-defined protocols and rules, such as Open Shortest Path First (OSPF), Border Gateway Protocol (BGP), Multiprotocol Label Switching (MPLS), and Spanning Tree Protocol (STP).

It's important to realize that in this model, the open nature of traditional networking starts at the edge of each network device. In other words, although the control plane of one router in a data center may talk to the control plane of another router using, say, OSPF, this only matters between devices. Within each device, the interface between control and data planes is actually very closed and proprietary. In traditional networking, exactly how the OSPF protocol in a device's control plane causes changes in the forwarding database consulted by its data plane is nobody's business.

SDN opens up the interface between the control and data planes, making it possible to move the control plane completely outside of network devices. With the two planes no longer linked through proprietary communication, agencies can build control planes and network configuration systems unlike anything currently available, smoothing over thorny networking problems in the process.

SDN isn't an improvement on existing networking; it's a different kind of networking. For many data center managers, SDN is of no interest at all. There is nothing fundamentally broken about the way network devices are designed today. And for most organizations, traditional network devices work well, with the right level of programmability and control. What some people object to is the complexity of configuring reliable networks. In many cases, this complexity prevents some network capabilities from being used properly.

Whether or not SDN is in an agency's short-term plans, there are steps that network administrators can take now, based on lessons learned from the technology's development, that may help simplify network configuration and pave the way for future SDN deployments.

Make DNS Work Properly

One of the most important lessons from SDN development is the need for network abstraction, and one of the most critical abstractions in networking is the mapping of names and addresses. IT managers who don't have a solid Domain Name System (DNS) in place should spend the time and money required to eliminate all dependency between IP addresses and applications, including system management. If IT workers are still typing in IP addresses when logging in to firewalls, switches and routers, then the DNS is broken and desperately needs to be fixed. An IP address management solution that makes it easy to translate IP addresses to names (and vice versa) is one of the best ways to simplify management and reduce the amount of work required to reconfigure a network.

Become Application-Centric

The first uses of SDN in federal data centers will likely focus on the proper configuration of switches, routers and firewalls. Configuration tasks that were impossible to manage before should be possible in the world of SDN. The keys to making good use of SDN will be understanding application architecture and defining the flow of information, both north-south (into and out of application tiers) and east-west (between application servers in the same tier).

Despite years of experience with enterprise application platforms, such as Active Directory and Microsoft Exchange, many IT and security managers have only the vaguest idea of how clients and servers interact. IT managers should build databases or management systems that look at applications as a series of layers and flows. Even in a non-SDN world, this type of mapping is invaluable to virtualization initiatives, where servers tend to multiply and the trend is to spin up another virtual machine rather than layer multiple applications on a single server.

Prepare for Distributed Hardware and Centralized Control

When network managers use SDN to centralize control architectures, they do it for a specific reason: Too many software and hardware components have created too much complexity. Migrating to SDN will be characterized by a reduction in large, centralized devices and greater use of distributed hardware. Network managers who have not moved to so-called top-of-rack topologies will find hardware vendors pushing them in that direction. This trend of moving network devices into server racks has been driven by high-density virtualization farms and will grow as SDN concepts take hold and vendors prepare for SDN as an option on newer hardware.

Over the next decade, data center networks built on SDN will be very distinct from other types of network systems, such as edge Internet connections or wide-area, virtual private network concentrators. IT managers who have merged functionality into Swiss Army knife–style devices should slowly switch to diverse machines, handling data centers separately from other networking functions, including user access, wireless, Internet and WAN connectivity.