In the opening post of this series on software-defined networking/networks (SDN), I introduced you to the purpose behind the “SDN Reality Check!” and how excited we are to share our learnings with you, the community, and involve you in the discussion!
So, how do you define Software-Defined Networking and Software-Defined Networks (SDN)?
“What?” you ask, “how difficult is that?!” And, you point us to either SDNCentral’s definition of it or Wikipedia’s definition of it, and a myriad other sources that attempt to define SDN.
One could also look at the writings of several industry experts and commentators, including Tom Nolle, who blogs here, and gave a nice introduction to some of his latest posts on SDN at our Carrier Ethernet Group here (note: thanks to the vagaries of LinkedIn, even though this link is supposed to take you directly to Tom’s comment, you’ll find that it takes you to the start of the discussion and you’ll need to scroll down to find Tom’s comments – complain to the powers that be on LinkedIn for that!).
Or you could read the insightful writings of Isabelle Guis, who has done some excellent analysis of several top SDN startups in our industry today (don’t forget to follow the entire 4-part series, which covers 13 startups), or Mike Fratto (ex Editor-in-Chief of Network Computing, now of Current Analysis), who had a contrarian view of SDN some months ago.
The initial thoughts for our Roundtable#1 came from my discussion with IBM Distinguished Engineer, Dr. Casimer DeCusatis, who is associated with IBM’s System Networking Division, and who writes on a blog for the OFC/NFOEC, in which he covers, among others things, SDN. After a telecon, Casimer and I, put a stake in the ground, and advanced the defining characteristics of SDN that we figured could serve as a litmus test to assess any new advancement/technology. One could capture those in 5 attributes (which we realized would likely be controversial) and say that SDN must:
1. Separate the control plane, data plane and management plane: For example, so that network control and management can be accomplished from a server outside the network which talks to all the switches in the network.
2. Move towards centralized management: in contrast to the strictly distributed approach prevalent today. This is a consequence of separating the control, management, and data planes; we will not abandon distributed approaches, but centralized control is a tenant of SDN and offers key advantages
3. Virtualize the network in the same way that we have virtualized the server. In other words, the benefits that we got by virtualizing the server (where a person could dynamically change the server allocations etc. using commands and automated control, without knowing all the gory details of what it took to make this happen) should be available via SDN for virtualizing the network.
That is, we should be able to make changes to the network dynamically without having people with extremely specialized skills to do that. This may require a combination of overlay/underlay networks working together with OpenFlow, and includes the use of virtual hypervisor-based switching elements.
4. Be built on open-industry standards. In other words, a one-vendor network is not acceptable, and standards must be defined (and products compliant to them) such that different vendor SDN products can seamlessly interoperate. Some examples of SDN standards in the works include OpenFlow, VXLAN, NVGRE, and DOVE; note that none of these are required to call a solution SDN, but they represent different aspects of realizing an SDN solution. So, if you use these standards, you are doing at least a part of SDN, but you don’t have to use all these standards to call the solution SDN.
5. Be disruptive – that is, have the ability to displace legacy technology and enable new value chains. That is, not only must SDN technology provide a new value proposition, it must provide a *faster time to value*. As a disruptive technology, SDN also offers value propositions such as virtualizing the network, making the network dynamic (workload-aware, and multi-tenant, and compatible with cloud attributes), and enabling new value chains (not just reduce capex/opex).
So, what is your definition of SDN? Where have you found it to be defined best? Does the definition differ, depending on whether we’re talking of the data center or a service provider core IP/MPLS or transport network? Should it differ (or should there be some commonality)?
You may share your comments below, on our Carrier Ethernet Linked In Group (where discussions are ongoing), or register here, and submit your top 3 questions for possible consideration at a subsequent Roundtable or on the Panel (for details, scroll to the bottom of the page) at the MPLS & Ethernet World Congress 2013, on March 20th!
Let us hear from you!