This week at Interop, the term software-defined networking (SDN) was used in such varying contexts that I wondered if it was going to go the route of terms like cloud, NAC, APT and any other catchy phrase that smells of hype. Why? Once a term is used to mean anything, it means nothing. Many of the clouderati complain that cloud presentations start with a cloud definition. They're sick of hearing it, but the need to constantly define cloud means it has lost any relevant meaning.
Case in point: I had the opportunity to talk with Allwyn Sequeira, VMware's CTO of security and VP of security and network solutions, about what the company is doing in networking. It's neat stuff and I'll write more later, but toward the end he said VMware's virtual networking is a software-defined network--to which I said it wasn't. The dynamics of networking in virtualized scenarios are interesting and require unique products and features to support app and VM mobility, hybrid scenarios and the like. Someone (I don't remember who) said on Monday's SDN workshop that if the networking vendors don't solve virtual networking problems, VMware will. For better or worse, VMware is working the problem and apparently trying to co-opt the term SDN along the way (or maybe signaling future plans).
When I think about what makes an SDN unique from networking or virtual networking, it hinges on the word defined. Sure, Cisco's IOS or Juniper's JunOS are software systems that implement algorithms and routing protocols to define the paths through the network, but is that enough to satisfy the requirements of software-defined networking? If you think yes, they why do we have the term SDN (which I don't think was created by marketers)? If we have a new term, it ought to indicate something new, right? If you think not, then we have to define what makes SDN different from what networking does today.
The Open Networking Foundation (ONF)--the organization shepherding the OpenFlow specification through to standards--is at the forefront of SDN. Its SDN definition, published in "Software-Defined Networking: The New Norm for Networks," focuses on three key features:
The report says, "Software defined networking (SDN) is an emerging network architecture where network control is decoupled from forwarding and is directly programmable. Network intelligence is (logically) centralized in software-based SDN controllers, which maintain a global view of the network."
The Open Networking Summit's graphic to the left illustrates the separation argument very well. On the left, individual devices form a map of the network in cooperation with their neighbors, and then populate their forwarding engines with paths through the network. It's how networks have worked, and they work well. On the right, an SDN separates the control plane--the purple rectangles on top--from the forwarding devices on the bottom.
The centralized view and the separation of the control plane and the data plane means that the SDN controller can create a physical topology--I'm not using the term L2 topology on purpose, since that implies more than the physical topology--of how nodes are connected and, based on some combination of algorithms, create paths through the network. Finally, the paths are programmed into the devices' forwarding engines. That allows the SDN controller to better manage traffic flows across the entire network and react to changes quicker and more intelligently. How well the controller defines those paths is, of course, critical to the operation of an SDN.
That brings us to programmability. SDN abstracts the network much like an OS abstracts the applications from that hardware. The ONF white paper above has this graphic depicting the abstractions:
Why would you want to program the network? Think about the ways that we perform tasks today, like enforcing quality of service. If we have two apps--a file transfer that needs capacity and an interactive app like VoIP that needs low, consistent latency--we use QoS marking to tell the network to treat the packets differently and, when congestion occurs, which ones to queue up and drop first. It works OK, but when the network is congested, performance suffers.
If you have multiple paths through the network, wouldn't it be useful to be able to, in real time, move that file traffic to a path that has capacity but perhaps has more hops? Doing so would open more capacity for the latency-dependent traffic and, in the end, both applications get better performance.
Consider a security context where you want to ensure that a set of users can only access a set of resources. You can do it with firewalls, access control lists and user identity, but that integration works only with a subset of pre-integrated products. With an SDN, you could enforce access control in your network. Naturally, you need a common protocol to do that, and OpenFlow is one example, but it is not the only way to implement an SDN.
It's important to remember these distinctions between an SDN and virtual networking because network overlays such as VXLAN or NVGRE have distinct advantages, such as hiding layers of addressing between the physical and virtual network, providing better mobility for entire groups of servers and services to different locations regardless of the underlying L2 network, and creating adjacency of virtual hosts in the virtual network, regardless of their physical location. Doing networking in software doesn't make it a software-defined network.
VMware's virtual network is a software virtual network. VMware's virtual networking doesn't have the other hallmarks of SDN, such as separation of the control plane from the data plane, which are still combined in the virtual and physical switches. It also doesn't have the programmability of forwarding paths, such as the ability to directly determine the path a flow will take in the network. It's companies like Big Switch, Contextream, Embrane, NEC and Nicira that are bringing those features to the market.
I'm using VMware as an example, but there are and will be other vendors, particularly in networking, that will try to co-opt SDN to mean everything from simple overlays to API/SDK-enabled configuration control, which does not define the network but simplifies hardware management.
Discover the benefits of scalable backbone and network services for application and cloud providers.
Network automation is gaining momentum. Here's how you can drive this powerful technology to its full potential.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
