Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

Start now!
back to overview

Centralized Control Is Not Centralized Control Plane

Every other week I stumble upon a high-level SDN article that repeats the misleading SDN is centralized control plane mantra (often copied verbatim from the Wikipedia article on SDN, sometimes forgetting to quote the source).

Yesterday, I had enough and decided to respond.

The original response is in quotes; I wrote additional explanations so I’ll be able to quote this blog post in future.

Would everyone please get the terminology right? Central controller (or centralized visibility or central policy engine) is not centralized control plane.

Control plane in network devices (or distributed systems) is a well-defined concept that implements not only routing protocols (as is commonly understood), but also real-time protocols like spanning tree BPDU, LACP, link failure detection mechanisms like BFD and UDLD and even host-to-network protocols like ARP. More details in:

The former makes perfect sense, particularly when combined with business-as-usual distributed forwarding to augment its behavior, the latter makes absolutely no sense in real world, no matter what its proponents claim.

Centralized control, be it configuration or policy management, traffic engineering or exception routing (aka PBR) significantly simplifies hard-to-solve problems that benefit from centralized visibility. Controller-based networks (or orchestration systems if you prefer that terminology) have a bright future. They also have a long history – there are numerous home grown or commercial products that implemented some variant of centralized control for decades (example: Cariden MATE or service provisioning systems).

Centralized control plane (implementing a reasonably complete set of control-plane protocols, including host-to-network protocols and fast failure discovery) cannot scale, as every implementer of a commercial OpenFlow-based product had to admit sooner or later. Let me just list a few examples:

At this point it’s worth noting that all traditional centralized networks (Frame Relay, SDH/SONET, even SNA) always contained some local intelligence, because that’s the only approach that scales.

Please note that this argument has nothing to do with OpenFlow. Any system with centralized control plane failed to scale, starting with Ipsilon Networks and Cisco’s Multi Layer Switching.

Further reading:

Product-specific blog posts:

You might also want to explore my other SDN- and OpenFlow-related blog posts.

For even more details, explore my SDN webinars and other SDN resources:

15 comments:

  1. Nice SDN summary:
    http://www.ittc.ku.edu/~fli/eecs712S15/read/SDN%20survey.pdf

    -bgolab

    ReplyDelete
    Replies
    1. They definitely invested an enormous amount of time and energy into it. Too bad it focuses on what they call "canonical SDN", which I still claim is not exactly relevant (which they somewhat admit at one point, and then carry on).

      Delete
    2. Yes, huge effort. And huge document to read at once;) They also admit the existence and rationale of hybrid approach where the existing distributed control plane is enhanced by 'centralized controller' (following your vocabulary). They also mentioned classical approach shortcomings (scalability & resilience issues). Seems to be very close to your opinions about the SDN.

      Delete
  2. There is a very good free class on SDN offered through Coursera

    https://www.coursera.org/course/sdn1

    ReplyDelete
    Replies
    1. ... and for real-life perspective you can always watch my webinars. Unfortunately most of them are not free ;)

      Delete
    2. planning to get a few of yours soon :)

      Delete
  3. I agree, and I disagree... Centralized calculation of reachability and topology is what most people think of when they think "SDNs." I've started using the term "programmable network," as a stand in for solutions that centralize policy while distributing reachability calculation, and the like. We definitely need a divide that will make this stuff scalable, but we're not really _thinking_ about what that divide should look like.

    We're just running around centralizing willy nilly. We need to sit for a spell and think about what it is we're trying to do, and why.

    ReplyDelete
  4. How about we put you, Russ, Ivan and Peter Lapukhov in a room for a couple of days and you do some thinking. I'm sure great stuff would come from it :)

    Russ, what's your take on SD-WAN? Would you call that SDN or simply programmable network.

    ReplyDelete
    Replies
    1. I would love to do that, but it seems like Petr got a gag order from the dark side :(

      Delete
  5. Centralized management has of course existed since the dawn of time. I remain confused regarding centralizing "policy" or control-plane functions; specifically what happens when a network node receives an incoming data packet or frame. Does the node have to hold the packet, communicate with the SDN controller via OpenFlow, wait for a pass / fail message (a la RADIUS), then forward the actual packet(s)? Or, is the concept to have a single gigantic "policy" / ACL for the entire network which gets pushed down to every poor little network element? I feel like I'm missing some key concepts driving the SDN bandwagon.

    ReplyDelete
    Replies
    1. I don't think I wrote a blog post on this specific one. Time to fix that ;)

      As for "do we have a single gigantic policy which gets pushed down" - smart implementations don't do that, but figure out what needs to be pushed down into each element, and only push down the absolute minimum of rules.

      Delete
    2. Turns out I did write a blog post on this topic ;))

      http://blog.ipspace.net/2013/03/controller-based-packet-forwarding-in.html

      (Note to self: use Google before pressing the "Publish" button, not afterwards).

      Delete
  6. Great Post. We at CPLANE NETWORKS have been touting the benefits of multi-protocol centralized service orchestration for a long time. Whether it's bandwidth management, path computation or "service stitching" for example, provisioning vxlan overlays and mpls vpn with path/quality control together to provide a higher service offering, the need is to understand each device and it's capabilities in an overall system. For a long time OpenFlow and control plane have taken most of the oxygen out of the room. As focus shifts from the limitations of OpenFlow/control plane the focus is going to centralized service orchestration. The key of successful orchestration is being able to straddle newer and older technologies. Service Orchestration by nature is never green field.

    ReplyDelete
  7. Great post (again) Ivan. This knowledge helps to bridge the gap between what management thinks SDN is (read: what vendors tell them) and what it really means when using it in production. Of which I only see demo/lab implementations. Vendors will equate lab/demo with production so it looks good in marketing sheets.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Sidebar