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

SDN: ONF Is Moving to “Logically Centralized Control Plane”

Open Networking Foundation has this nice and crisp definition of SDN:

[SDN is] The physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices.

Using this definition it was easy to figure out whether certain architecture complies with ONF definition of SDN. It was also easy to point out why it was ridiculous.

In case you can’t be bothered to read the whole blog post, here’s a short summary of my opinion of this definition. It’s a slide from my Introduction to SDN presentation, which is part of the SDN workshop as well as numerous SDN presentations I had in the last years.

While the ONF web site still features their marketing definition of SDN, I wanted to dig deeper while writing my Centralized Control != Centralized Control Plane blog post (read also the follow-up post), and focused on SDN Architecture 1.0 document (published in June 2014).

The SDN Architecture document was obviously written by people with real-life networking experience (as opposed to academics and marketers) and contains a large number of really interesting statements (see also RFC 1925, section 2.4).

If you’re even remotely interested in SDN, you (RFC 2119) SHOULD take the time to read it and think about what it’s trying to say and what the implications are.

Let me quote a few of those statements (obviously out of context – but then I told you to read the whole document, right?).

Please note that I’m not bashing the SDN Architecture document. Its authors did a marvelous job; I’m just pointing out what happens with a seemingly simple concept once someone tries to implement it and gains some operational experience.

The descriptive overview of SDN contains this note:

The concept of a data plane in the context of the SDN architecture includes traffic forwarding and processing functions. A data plane may include the necessary minimum subset of control and management functions.

Exactly what I’ve been saying for years – you cannot run linecard protocols (BFD, LACP, LLDP…) from the central controller. Section 4.2 of the document agrees with my sentiment:

The data plane implements forwarding decisions made in the controller plane. In principle, it does not make autonomous forwarding decisions. However, the controller plane may configure the data plane to respond autonomously to events such as network failures or to support functions delivered by, for example, LLDP, STP, BFD, or ICMP.

Did you notice that they talk about controller plane and not control plane? It’s also worth noting that the current version of OpenFlow doesn’t provide any functionality in this direction. For more details, watch my OpenFlow Deep Dive webinar.

Section 4.3.4 (Delegation of control) is a nice summary of the fundamental shift caused by exposure to real-life problems (all emphases are mine):

Although a key principle of SDN is stated as the decoupling of control and data planes, it is clear that an agent in the data plane is itself exercising control, albeit on behalf of the SDN controller. Further, a number of functions with control aspects are widely considered as candidates to execute on network elements, for example OAM, ICMP processing, MAC learning, neighbor discovery, defect recognition and integration, protection switching.
A more nuanced reading of the decoupling principle allows an SDN controller to delegate control functions to the data plane, subject to a requirement that these functions behave in ways acceptable to the controller; that is, the controller should never be surprised. This interpretation is vital as a way to apply SDN principles to the real world.

I don’t know who wrote the SDN Architecture document, but the parts I’m really interested in sound like a description of Big Cloud Fabric architecture ;)

Finally, I found this gem in section 4.3.2 (SDN controller):

Controller components are free to execute on arbitrary compute platforms, including compute resources local to a physical NE [network element].

To summarize:

  • Components of the control plane can be implemented in the data plane;
  • SDN controller can delegate some of the functions to the data plane network elements;
  • Controller components can reside on network elements.

Takeaway: Based on this broad definition, almost anything with a central control element (aka NMS or orchestration system) can be called SDN (so SDN is really becoming as meaningful as cloud).

7 comments:

  1. So basically marketing guys wrote the "physical separation of the control from the data plane" nonsense and now the people people with real-life networking experience have to "redifine" the definitions of control and data plane in context of SDN (where data plane includes control plane functions and control plane is actually a controller)? They could have just fixed the initial definition to make sense :)

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete
  3. The contributors are mentioned in the end of the ONF's document. And, surprisingly, there is nobody from Big Switch Networks :)

    ReplyDelete
  4. We are in full agreement, as very often :)
    People who have been building working and sustainable networks for long time know what it takes to do it properly. One can play politics and marketing for some time but when it comes to real deplyments, BS gets exposed rather quickly!

    ReplyDelete
  5. Very much appreciated, Ivan. We in the ONF architecture working group have been trying to get this more nuanced message out for quite a while now.

    ReplyDelete
  6. When the NMS failed, they called it SDN. When collocation and off-premises hosting failed, they called it Cloud. IPv6 did not see the light due to several reasons. You cannot kill the TCP/IP technology overnight. Managing it will remain the same, call it SDN, NMS or other.
    Does SDN bring "more programmability"? More code? Who needs that? IF so, how does it simplify?
    If not, what capabilities and visibility are missing in SDN?
    Can anyone answer those?

    ReplyDelete
  7. Hi Ivan

    You blog opened my eyes!


    For weeks I tried to understand what changes brings SDN (cloud and nfv as well) into architecture but without too much luck :)

    In my opinion all the new names, terms, products from vendors and OPEN things are a bit fake and only introduce confusion.

    Nevertheless I clearly see potential and usage for SDN, VNF and Cloud if deployed in a smart way.

    Michal

    PS
    I thougt that you promote SDN Ivan ;)

    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