SDN Controller Taxonomy
Even though Gartner declared SDN obsolete before plateau in their 2021 Networking Hype Cycle, most vendor marketers never got the memo. Anything that interacts with network devices in any way1 is called an SDN controller. Let’s try to throw some minimal amount of taxonomy into that mess based on how these controllers interact with network elements (physical or virtual).
Centralized control plane solutions are what Gartner considered to be SDN. Apart from a few well-architected niche solutions2, the laws of physics won. Centralized control plane was always a bad idea, and most people involved in the SDN orthodoxy eventually realized that after sobering up from a hype-induced trip3. Nothing much to see here.
Controllers interacting with the control plane. Most SD-WAN controllers are in this category. At the very minimum, they have to act as BGP route reflectors: collect reachability information from the SD-WAN appliances and distribute it to other appliances.
Network virtualization controllers4 are often in this category as well. Many of them use a control plane protocol (often EVPN) to interact with the outside world… although I wonder whether that’s a good idea. It’s interesting to see the gradual move away from the control plane interactions in VMware NSX Controller5 – as the product is built on ideas that came from one of the early proponents of centralized control plane, they must have hit some interesting scaling problems to move in that direction.
Orchestration systems. Why would you want to call a system that provisions a service by configuring the network elements in the background an SDN controller? Oh, it’s like bridge and switch – the marketing needed a flashy new name for an old idea, and SDN was all the rage when they made the decision.
Even in this segment, there are solutions that provide true abstraction of services. A prime example is probably Cisco ACI with its endpoint groups and contracts.
Then there are solutions provisioning group policies and network services across a range of network elements. For example, you could configure a VLAN segment implemented with VXLAN and EVPN (or LISP) on all edge switches in your fabric, or an SSID across a set of wireless access points. Cisco SD-Access, Pluribus Unified Cloud Fabric, and Ubiquity UniFi SDN Controller are probably in this category.
Finally, you might encounter someone rebranding a traditional device-focused network management system into an SDN controller, proving that the marketing shenanigans are indeed limitless.
Have I missed something?
Your comments (preferably including links to documentation) would be most welcome, including further examples of products in each category.
In case you want to send me a private message, you already have my email address if you have an ipSpace.net subscription, or if you’re subscribed to my SDN/automation mailing list, and there’s the Contact Us form for everyone else.
-
Even when it’s using an Ansible playbook with screen scraping over an SSH session ↩︎
-
Including a surprisingly-stable and working SDN controller. ↩︎
-
Some of them with an enormous headache, in particular when they worked for a vendor that bet the farm on OpenFlow. ↩︎
-
Including most large-scale public cloud implementations. ↩︎
-
Now part of NSX Manager ↩︎
SR-MPLS with a PCE might be an example that fits into the "interacts with the control plane" category. I'm not that familiar with it so I'm not sure if you need to do config changes to tell a router to use a PCE path or if that's included in PCEP.
PCE controllers are definitely in the "interaction with the control plane" category, regardless of whether they're used in traditional RSVP-TE, SR-MPLS, or SRv6 environments.
I might be missing something, but it looks to me like PCE was designed to find paths for TE tunnels that have been configured through some other means. There's also an option of creating tunnels "out of thin air"; I'm assuming you need something like IGP autoroute to make them work.
OF took a beating because of the "just send the unknown packet to the controller" behaviour. It didn't scale at all, it was often the reason OF was cast as an 'academic' pipe dream. In truth, to build a network that rivals MPLS-VPN you don't need that feature at all.
I've often thought of trying to replace Openflow, OF signalling, Ethernet transport, etc. in the SDN and SDN controller with counterparts from the world of MPLS. An SDN controller is essentially a PCE, replace the OF protocol with Netconf (or your flavor of the day). PCEP comes close to what's required but something was always missing:
The ability to send/detect crafted traffic from the control plane, through the data plane and back again is missing from any current IP network architecture I can think of. In an OF SDN I can craft a packet in the controller, send that packet via the control plane to any switch and have that packet sent on a data plane link. I can program the rest of my switches to detect such a packet, stamp it, and send it back to the controller. Need to detect physical links in an OF network? Need to send a packet down a customer pipe to confirm the service? It was a really handy feature and I don't think it exists in the IP world today. Without such a feature, we won't get true controller-based networks in IP.
for background, i was at Juniper during the creation of Northstar, was a big internal user of the WANDL acquisition upon which it was based, and I ran the Telstra SDN for 3 years.
While the idea of sending crafted packets from any interface and getting them back sounds great (and I know people who did exactly that with static MPLS labels and crafted MPLS label stacks), you cannot use that for anything that needs to scale (= ARP) or has to be real-time (= BFD).
I'm pretty sure you can get close to "send a packet down a customer pipe" with some MPLS and FlowSpec tricks, but of course it's ugly.
In the end, OpenFlow is a nice way of programming TCAM (= packet filters) and doing special stuff like we're discussing now, but they were selling it as a game-changer (and a few people got $1.26BN out of that pipe dream).