SDN Will Win -- But Which SDN?SDN Will Win -- But Which SDN?

The division is between "deep" and "shallow" implementations of Software-Defined Networking.

Is SDN about OpenFlow? So says the Open Networking Forum (ONF) and a lot of smaller vendors. Is it about MPLS and BGP and maybe rich APIs? So says Cisco. VMware thinks it's about software virtual networking a la Nicira, and Alcatel-Lucent thinks that's only part of the story--there's a deep SDN and a shallower one. And then we get to vendor-proprietary flavors. This is what you get when the media rewards with publicity any vendor who says "SDN"!

But SDN is a winner. It's just a question of which SDN we mean.

The key to SDN understanding is the notion of "deep" and "shallow" SDN. Software virtual networking--what players like Nicira and Nuage promote--is "shallow" or higher-layer SDN because it rides as traffic on actual network trunks and switches/routers. What this level of SDN provides for is essentially unlimited segmentation--unlimited numbers of virtual networks. The near-term focus of the need for that sort of thing is the multi-tenant cloud data center.

In contrast, the "deep" SDN model actually works to influence packet forwarding in network devices. You can segment data centers with it, and that's probably the most common application proposed so far.

So it seems there's a collision of missions of our two SDNs in the data center--or maybe it's a cooperation.

In a big data center with a lot of switches, traditional networking leaves enterprises facing a challenge of traffic engineering and failure management. Ethernet protocols like Spanning Tree don't support multiple routes, so you end up building a hierarchy of switches. Each level you go up from the bottom, you get more traffic and more issues with traffic engineering to sustain QoS across the structure.

Deep SDN can fix that by letting you build configurations of switches that have as many trunks as you want, that home to different partner switches, and that in general mimic the loose structure of routed networks.

Shallow SDN can't help with traffic management, but it has the enormous advantage of being based on virtual technology. I build a shallow SDN network from tunnels and vSwitches, not big iron that cost me a mint and that will cause my CFO seizures if it gets obsoleted. Virtual stuff is definitely low-cost and low-inertia, so I can get the benefits of segmentation and connectivity control right now, at little or no incremental cost. And that's where the cooperation/collision question comes.

Suppose I do shallow SDN--so I've now addressed segments and connectivity management. I still have traffic engineering issues, but if I were to use fabric switching or some more data-center-centric standards (Priority Flow Control, Data Center Bridging, TRILL...) could I not achieve the same goals, or at least achieve them using more of the gear I've got today and with the support of the vendors I'm committed to? That's a big question, because if the answer is "Yes!" then shallow SDN might not only win, it might limit the penetration of deep SDN by empowering other options--at least in the data center.

The other area of deep/shallow SDN interaction is in end-to-end SDN support. I noted that both deep and shallow SDN today seem focused in the data center. How about the branch, or the metro or WAN? In the case of shallow SDN, the problem has been that you need a software client to get onto a shallow SDN virtual network, and that means adding functionality somehow in the edge devices. In the case of deep SDN, the challenge is that the problems of central management of connectivity expand rather significantly when you get out of the data center and away from its very high capacity trunks, to the wider network. There, transport costs money and is limited in speed/capacity, so you can't over-engineer your way out of complexity.

Any branch device could in theory host a software virtual network client supporting a shallow SDN architecture, making that architecture end-to-end. If we started thinking of a branch location as being supported by a server with a network interface, it would be even easier to extend shallow SDNs from ponds to marshes, so to speak. And if that happened, would it not change the whole WAN-SDN picture as much as it could change SDN in the data center?

We do WAN traffic engineering today with traditional IP networks. It's very possible that shallow SDN technology, which can support traffic statistics per virtual network, could provide information to a network management system, from which that system could control loads and routes using the stuff like MPLS that we already use. MPLS sets up forwarding table entries, after all. Does doing it with OpenFlow instead create any utility?

Maybe. To many the SDN revolution is more about unseating incumbent vendors than it is about providing any conspicuous benefit. But our titchy CFO isn't going to like the "out-with-the-old" view of network upgrades unless the "in-with-the-new" part makes a significant improvement in economics. The shallow/deep SDN model might just focus the SDN debate where it belongs, away from technology and into benefits.

Follow Tom Nolle on Google+!
Tom Nolle on Google+