SDN: Software Defined Networks, the new SDN book by Thomas D. Nadeau and Ken Gray, does what any publication about a new technology should -- describe the basics.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
This doesn't mean that centralized control is doomed in the future, but it's hard to say in the long run whether centralized control is going to win out entirely.
co-author, SDN: Software Defined Networks
But the book goes beyond architectural strategies, controller choices, and the roles of network virtualization and network functions virtualization (NFV). Nadeau, a distinguished engineer at Juniper Networks, and Gray, a Juniper technical strategist, also take a few decidedly pointed stands on the future direction of SDN. They posit that the celebrated role of OpenFlow and the concept of centralized network control are only subsets of SDN.
The authors highlight the difference between software-defined networking and software-driven networking, explaining that the latter is about network programmability, which doesn't depend on a centralized control plane that directs dumb network devices. In the early days of SDN, many believed that centralized controllers paired with inexpensive, bare-metal network devices -- an approach that mirrors the server virtualization industry -- was the true path toward network programmability.
In their introduction, Nadeau and Gray write, "In the software-driven approach, one views OpenFlow and that architecture as a distinct subset of functionality that is possible. Rather than viewing the network as being comprised of logically centralized control planes with brainless network devices, one views the world as more of a hybrid of the old and the new. … It is unrealistic to think that existing networks are going to be dismantled wholesale to make way for a new world proposed by the ONF [Open Networking Foundation] and software-defined networks."
Nadeau and Gray spoke to SearchSDN about their SDN book, basic technologies and the future of the market. Here are some excerpts from that conversation.
In your book, you outline the difference between centralized and distributed SDN architectures. Is there one that will dominate?
Ken Gray: They will have to cohabitate for at least a while. Right now, distributed routing or distributed control is what's in the network. SDN works in some domains -- and you can replace [specific segments of] infrastructure in a shorter period of time than you can in wide area networks, [for example].
Also, we have tried central control in the past and we have several examples going back to SS7 Signaling System 7) that have met with varying levels of success. This doesn't mean that centralized control is doomed in the future, but it's hard to say in the long run whether centralized control is going to win out entirely. The idea of controlling everything from one point works well in a geography where control is relatively short -- otherwise you run into problems with the length of loop. [On the other hand], if I say I can solve that by distributing controllers and federating controllers, you start getting into distributed computing again, only at a higher level. In the end, things have to be hybridized.
You've got a chapter on SDN controllers. Once upon a time, that would have been strictly an OpenFlow conversation. How do you lay out controllers in the book?
Thomas Nadeau: We tried to describe two things -- one is to provide a review of the space, explaining the most popular controllers out there. The other thing we do is to actually show the controllers progressing … along a trajectory toward satisfying this idealized SDN controller framework. When you go through the description, you get to the end and you find that the OpenDaylight controller is the closest to the idealized framework. That's what we used at Juniper about 18 months ago as a means of guiding what we were trying to build.
Gray: The solutions that are based on a pipeline approach, where you have to use [a proprietary or standard] northbound API [application programming interface], stagnate the SDN market. Since we wrote that chapter, we have seen more vendor-specific and southbound-specific [technologies]. They don't solve the initial problem SDN was trying to solve -- service providers can't innovate, they can't put anything new in their network with monolithic OSSs [operations support systems]/BSSs [business support systems] to achieve the automation they need for service rollout.
What we envisioned when we were writing this was a framework that allows you to use all of the southbound [interfaces] out there. Some are designed for wide area networks, some are designed for cheaper switches in data centers, and you should be able to craft end-to-end solutions with all of those. And as an application developer, you shouldn't care what southbound [interface] your customers pick. The only way is a common framework and a common API. In the end, we are not solving the problem unless we find a … framework that incorporates the best of all of these that is achievable through open source.
Chapter 9 talks about multiprotocol, potentially open source SDN. You don't have it defined for you by a specific vendor -- it's a de facto standard. If an open source project like OpenDaylight provides robustness for commercial environment, then you have that de facto standard. There's not a really good chance that all the individual vendors, with individual controllers and interest in winning the API battle, will ever reach that point.
You two work for a vendor that has an open source controller, but also has proprietary technology. What do you tell customers?
Nadeau: There are three different ways to define a standard: One is you define the northbound and southbound APIs, but the problem is that implementations don't easily match those theoretical plans. There is another more extremely vendor-proprietary implementation, which is the complete opposite. There is a third method, which is what open source software is doing -- it's the sweet spot for defining these APIs. There is a reference implementation and a number of burgeoning enterprise implementations of APIs, and the community is getting together [around this].
What I tell customers is you should advocate for openness, but if there is a compelling application out there that is tied to a vendor solution -- data center orchestration for example -- you can afford a vendor proprietary solution because the ROI should be there for you.
Why is there a whole chapter in your book on NFV? I thought that SDN and NFV were not necessarily the same thing.
Nadeau: The most salient [SDN applications] fall under operations and management. We are focusing on programmability. That is what makes a modern NFV solution that incorporates SDN constructs and optimizes the old way, which was manual.
More on SDN basics
A guide to understanding the OpenFlow protocol
A guide to understanding northbound APIs
Vendors take alternatives to OpenFlow
Dave Meyer on keeping OpenDaylight truly open
Gray: Is NFV bound to SDN? Not exactly, but it's made a lot easier through centralized control.
Virtualization of these machines might be the way the industry is going overtime as the Intel curve starts to win for firewalls and load balancers. Those virtual machines are tied to an orchestration system, and every orchestration system out there uses SDN.
Nadeau: NFV existed well before SDN. We were just doing this manually. In a service provider network, you would do function virtualization placement using physical devices. What's different now is that you can pick and choose where it exists and on what devices.
You have a chapter on SDN use cases. If you had to write that chapter two years from now, would the types of use cases be totally different than they are today?
Gray: A lot of the use cases we have today follow very similar archetypes. [In one, we are] replacing static, vendor-driven CLI [command-line interface] configuration with forwarding plane entries.
The second archetype is this agility in provisioning. Many of the applications in the use-case chapter are different instantiations of that archetype. I provision the infrastructure; I watch it for a while; I say, 'This is inefficient,' and with an online tool there will be feedback where it says, 'This is provisioned wrong, let's move this service here and move these users to this part of the network so we get better [performance].'
But there are probably other archetypes out there that will develop.
The views and comments expressed by Tom and Ken during this interview are their own personal views, and are not necessarily those of their employer, OReilly and Associates or anyone else.