What is SDN?
Software-Defined Networking has become one of those industry buzzwords that quickly gets so over-used and distorted that it is hard to tell what it really means or if it really matters. In this blog post I'll try to go back to the basics of what is SDN and how it is likely to impact the network administrator.
SDN was defined by the Open Networking Foundation (ONF), a standards group founded in 2011 by Deutsche Telekom, Facebook, Google, Microsoft, Verizon, and Yahoo!, as an architecture that "brings direct software programmability to networks worldwide." ONF is pushing this goal by defining and driving an OpenFlow interface. The ONF website describes OpenFlow as follows:
"In a classical router or switch, the fast packet forwarding (data path) and the high level routing decisions (control path) occur on the same device. An OpenFlow Switch separates these two functions. The data path portion still resides on the switch, while high-level routing decisions are moved to a separate controller, typically a standard server. The OpenFlow Switch and Controller communicate via the OpenFlow protocol, which defines messages, such as packet-received, send-packet-out, modify-forwarding-table, and get-stats."
So the basic concept is pretty simple, move the control functions into a software layer that talks to the hardware layer which still moves the data. The key benefits of this approach, especially if all hardware devices used the same interface protocol, is that it would be much easier to programmatically provision network resources and automate configuration tasks at a common software control layer.
This is largely what happens today in server virtualization. A software virtualization layer interfaces with the applications and manages the underlying physical compute resources (e.g., CPU, memory, disk, etc.). This abstraction has enabled a number of key capabilities including rapid provisioning, VM/application mobility, thin provisioning of storage, etc.
Big Vendor Positioning
The idea of abstracting the intelligence from the hardware naturally leads to the conclusion that the network virtualization layer would then be able to run on commodity networking hardware. This is not a scenario that is likely to be very appealing to Cisco and the other big networking hardware vendors. Looking at a parallel example in server virtualization, HP, Dell, IBM and others still sell a lot of servers even though VMware provides the most common virtualization layer. However, it is getting harder and harder to maintain any differentiation at the hardware layer which is driving commoditization and squeezing profit margins – not an appealing vision for Cisco and the other vendors who would be happy with the status quo. Larry Dignan's article "Cisco makes its software defined network case: Do you buy it?" does a nice job of diving into the Cisco perspective in more depth.
In July 2012 VMware stepped into the picture in a big way with their acquisition of Nicira who has been focused on network virtualization using an SDN approach. VMware is the dominant player in the server virtualization market so when they acquired Nicira for $1.05B it caught many people's attention. At VMWorld 2012 in San Francisco this past August, VMware continued to hit the theme of a Software-Defined Data Center that encompasses servers, storage and networking. The positive side of VMware's interest in SDN is that they have enough market presence already in the virtualization space that the other big players now have to be serious about moving forward with a SDN strategy of their own or risk losing their existing markets to VMware. On the other side, VMware already has enough market power with their server virtualization capabilities. It is scary to think about what they could do if they are able to successfully extend that dominance across both storage and networking as well.
So what should we expect from the big vendors like Cisco, VMware and others? The typical approach for those vendors would be to talk a lot about their SDN strategy, claim open SDN capabilities within their products and pursue activities that have some SDN capabilities while keeping it proprietary to their product line so that they can maintain control of the customer. With the existing VCE partnership between VMware, Cisco and EMC it will be very interesting to see how this dynamic plays out across network and storage.
How will this Impact the Network Administrator?
If history is any guide, the first challenge the Network Administrator will have to face is wading through the proprietary vendor features or capabilities marketed as SDN. The admin will need to determine where there is real value, what is designed strictly to lock you in to a vendor, and what is just marketing hype. In the longer term, SDN has the possibility of being a valuable capability that enables a transition to a more flexible and efficient network similar to what has happened with server virtualization. With standardized, open SDN capabilities, the network admin would be able to programmatically automate key provisioning, configuration and management tasks. This would allow more time to focus on business requirements and overall network optimization and less on device-level tasks. As this transition occurs, probably over the next two to five years, the network admin will want to make sure they are at least keeping up with those changes. By updating skills they can become the equivalent of the VMware (or Hyper-V, KVM, etc.) admin that can manage the physical server too instead of just being the legacy server admin.
Drawing another parallel, as the network virtualization layer does more, it will be harder to connect what is happening at the application layer down through the virtualization layer to the physical infrastructure. The network administrator will want to make sure that they can monitor the network and maintain visibility from the application and virtualization layer down into the physical infrastructure. This visibility enables both system troubleshooting and optimization. For optimization it ensures that physical capacity aligns with the virtualization demands. For troubleshooting you can quickly understand where network traffic monitoring or other analysis is needed to identify where the real problems are occurring and what the impacts are. Keeping that end-to-end mapping capability from the network hardware to the network consumers will ensure that the network admin remains a critical part of the overall data center team.
While this change is likely to happen over years instead of months, it is always good to use change to your advantage as opposed to being caught napping.
By Mike Thompson, SolarWinds Networking Product Marketing Manager; on twitter @michl121
build-access-manage at dayaciptamandiri.com
