Unlike a rigid OpenFlow deployment, Cisco Software Defined Networking (SDN) takes a more scalable approach to this paradigm shift in network connectivity. Although both architectures seem to agree on the division between the control and data plans, Cisco’s position seems to blur this separation a bit and perhaps for good reasons. To learn more about the control and data plane concepts, watch this great short video on What is a Software Defined Network.
The Open Networking Foundation (ONF) document made some interesting points that are highlighted below:
SDN makes the network not so much “application-aware” as “application-customized” and applications not so much “network-aware” as “network-capability-aware”. As a result, computing, storage, and network resources can be optimized.
[comment] Sounds pretty good.
“The future of networking will rely more and more on software, which will accelerate the pace of innovation for networks as it has in the computing and storage domains.”
[comment] Sounds pretty good.
“An OpenFlow-based SDN architecture eliminates the need to individually configure network devices each time an end point, service, or application is added or moved, or a policy changes, which reduces the likelihood of network failures due to configuration or policy inconsistencies.”
[comment] Sounds pretty good.
“Current IP-based routing does not provide this level of control, as all flows between two endpoints must follow the same path through the network, regardless of their different requirements.”
[comment] This is not true. There are technologies outside of SDNs that allow for multiple paths between the same end points (e.g. Cisco AVC) or more specifically Cisco Performance Routing.
“The OpenFlow protocol is a key enabler for software-defined networks and currently is the only standardized SDN protocol …”
[comment] This is not true. In researching for this post, I found no evidence of any IETF or IEEE recognized SDN standard. As of today, there are still no SDN standard.
In reading the Cisco Software Defined Networking document, they claim that their Open Network Environment (ONE) addresses several areas that are outside the scope of OpenFlow:
Facilities for element management and monitoring.
[comment] Operating system image management, hardware management, event triggering, and more are all important issues that will set SDN vendors apart.
Data packet payload manipulation (e.g. deep packet inspection, application awareness requiring payload inspection, ability to inject packets)
[comment] This is a big one! Identifying applications correctly is a real science that often involves studying a series of packets in a stream before the application can be accurately identified. This is probably one of the many reasons why the ONF <see above> makes the distinction between application-aware vs. application-customized. To be application aware, the switch or router needs to have intelligence and today this means expensive hardware. Without application awareness, we must compromise on the value gained from an ONF SDN.
Service deployment.
[comment] Cisco claims that OpenFlow has no ability to instantiate a service directly on a network element. (e.g. firewall, video monitoring)
Distributed control plane and APIs: OpenFlow’s reliance on a centralized control plan limits application run time options.
[comment] Unless the SDN capable switch has some proprietary intelligence about how the application needs to perform, service levels will suffer when traveling over WAN circuits or when connecting up to traditional (non SDN) networks. Example: If jitter or packet loss is impacting the quality of a phone call, a non SDN switch could make a decision immediately to reroute the connection saving milliseconds of delay by not having to request instructions from a busy controller.
Conclusion
The SDN wave is forcing hardware vendors to think differently about how to ease the burden of policy administration but, don’t be lead to believe that a rigid OpenFlow deployment will solve much of your application performance issues. To optimize the constantly changing nature of application performance, we will have to rely on proprietary SDN enhancements from vendors like Cisco, Extreme, Juniper and others. OpenFlow alone isn’t going to make your applications sing.