12:55 PM
Greg Ferro
Greg Ferro
Connect Directly
Repost This

SDN Is Not a Technology, It's A Use Case

Software defined networking is not a discrete technology, but rather a set of use cases that require a variety of technologies to meet customer needs.

Commentators on software defined networking (SDN) often point out that no one has deployed SDN, or you that can't buy SDN today. At a recent IETF meeting, someone stood up and said SDN stands for "Still Does Nothing."

This attitude fails to understand SDN is not a technology. It's more practical to define SDN as a bunch of use cases that use many technologies to meet specific customer needs. Think of it in terms of the data center. Sometimes people will talk about purchasing a "data center network," but that phrase encompasses a variety of different technologies and functions. Do you mean top-of-rack and core Ethernet switches? MLAG and TRILL capability? QoS, MPLS or virtual contexts? Do you mean the OSPF and STP pathing software?

Thus, a more reasonable discussion of SDN should focus the features it will provide and the technologies required to build it. Broadly speaking, SDN features deliver multi-tenancy, mobility, scalability and reliability on our networks. What differentiates SDN from existing networking is the use of controllers, APIs and software applications to achieve these features.

On the technology side, how you build and deploy SDN will vary according each network and the use cases of that network. Some networks will use OpenFlow, other will use SPB, TRILL, OSPF and others. The SDN platform you deploy might use the OpenDaylight controller or the BigSwitch Networks controller that interfaces to OpenStack. Or your SDN might be a full stack approach, such as Juniper's Contrail V, Nuage Networks' VSP or VMware's NSX, that provides a different type integration and feature set to manage virtual switches in the hypervisor. For service providers, it's likely that IETF efforts around I2RS will further enable "programmable MPLS" for WAN management to extend the tools that are available today, such as Cisco's Cariden. And a careful look at Metro Ethernet shows that SDN functions have already arrived with SDH/Sonet already supporting external configuration.

[Get insight into the relationship between SDN and OpenFlow in “SDN Is Business, OpenFlow Is Technology.”]

And for more specialized or niche requirements, you can develop your own application to use proprietary APIs such as Cisco's onePK for precise control over the network and its changes.

All of these approaches are Software Defined Networking. While some of the technology components are shipping today (as products or even updates to existing technology) many others are still under development. Vendors developing products seek feedback from the marketplace to determine if those products meets customer needs. This gives vendors insight into product viability and validates the investment plan. However, it also creates a good deal of uncertainty, which in turn generates a lot of noise that can distract from actual outcomes that these products create.

SDN is a major inflection in the curve of networking technology, but it's not a revolutionary product that solves all of today's challenges. Very few ideas in IT are new, and SDN is no exception. SDN is combining the useful features of existing products in new ways and adding some control methods with software interfaces that change configuration and operations. That's not a single thing, it's a strategy. In the same way that you don't buy a "Data Center Network" today, you won't buy "Software Defined Networking" tomorrow.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
8/15/2013 | 7:45:53 PM
re: SDN Is Not a Technology, It's A Use Case
I think it's a matter of timing, Greg. Silver Peak introduced it's Agility initiative last year, which showed how a virtual acceleration service could be controlled by an SDN controller. Could we have released a similar technology years previously? Perhaps. But the culture of virtual adoption, coupled with SDN advocacy by VMware and others, makes SDN introduction particularly timely.
Ali Kafel
Ali Kafel,
User Rank: Apprentice
8/15/2013 | 1:30:43 AM
re: SDN Is Not a Technology, It's A Use Case
I would say it's an architecture that fulfills specific use cases
User Rank: Apprentice
8/13/2013 | 5:39:27 AM
re: SDN Is Not a Technology, It's A Use Case
a very wise article, on the whole network is all about delivering a packet / to perform an action on to a packet with action written in it, sdn just changes the way we deliver the packets in a big network.
User Rank: Apprentice
8/8/2013 | 11:12:48 PM
re: SDN Is Not a Technology, It's A Use Case
Greg, nice entry. I am NOT a networking expert, but more of a generalist with a fairly solid foundation in most IT areas including networking. As I read your entry, I began to get a feeling of "deja vu". It finally hit me that your comments on SDN sound much like many comments I've read about Cloud Computing. Many vendors call their products Cloud Computing. I believe, like your statement on SDN, Cloud Computing is not a technology. It is more of an assembly of concepts: for SDN, your say multi-tenancy, mobility, scalability and reliability; for cloud, there is virtualization, accessibility, automation, pay-for-use, etc.). With these characteristics, a "product" or "set of products" can claim to be "SDN" or "Cloud Computing". I always am amused when one vendor or some analyst claims another vendor is not really "Cloud Computing". Both SDN and Cloud are up for interpretation....and evolution. We should all be more open-minded.
User Rank: Apprentice
8/8/2013 | 5:52:10 PM
re: SDN Is Not a Technology, It's A Use Case
I'm sure you are knowledgeable but if you ever had to architect/design the hw/sw that supports SDN you would know that it is indeed a very rich and complicated technology - that's why it is only now coming of age, the pieces had to be put in place.
User Rank: Apprentice
8/8/2013 | 4:52:43 PM
re: SDN Is Not a Technology, It's A Use Case
To some extent, I think projects like OpenDaylight and Floodlight are trying to build up an ecosystem by gathering broad support across a open source communities. This could lessen the need to port individual controller apps too broadly. I suspect we will see relatively wide adoption of a small number of controller platforms, and even where there are different platforms, it could be that companies contribute their controller extensions to one or more open source projects to reduce the porting costs.

-Mike Bushong
User Rank: Apprentice
8/7/2013 | 10:30:04 PM
re: SDN Is Not a Technology, It's A Use Case
And that's why I don't understand the network vendors who push OpenFlow like it's the be-all, end-all of SDN. Just because your switches support OpenFlow doesn't mean anything unless you a complete SDN architecture built out with a controller array and powerful applications that integrate into current systems. Only then will you be able to do things you couldn't have done previously and only then does it create value.

Except now there's all sorts of northbound APIs (REST, OnePK, etc.), controllers, and architectures all competing with each other and doing things differently. And the SDN applications will need to be tailored and certified for each system so you know it will integrate nicely and it's actually been tested. Want to do lots of fun stuff with dynamic QoS settings and Cisco phones? Well guess what, that application will only be available for OnePK (most likely) and Cisco switches. I'm guessing each architecture will start to develop an SDN App library and the one with the largest number of apps and the biggest eco-system is going to win out in the end. Because while the southbound may eventually standardize on OpenFlow (and even that is up in the air), the northbound and controllers are being developed with a wide range of APIs and technologies and they often come with proprietary built-in.
More Blogs from Commentary
SDN: Waiting For The Trickle-Down Effect
Like server virtualization and 10 Gigabit Ethernet, SDN will eventually become a technology that small and midsized enterprises can use. But it's going to require some new packaging.
IT Certification Exam Success In 4 Steps
There are no shortcuts to obtaining passing scores, but focusing on key fundamentals of proper study and preparation will help you master the art of certification.
VMware's VSAN Benchmarks: Under The Hood
VMware touted flashy numbers in recently published performance benchmarks, but a closer examination of its VSAN testing shows why customers shouldn't expect the same results with their real-world applications.
Building an Information Security Policy Part 4: Addresses and Identifiers
Proper traffic identification through techniques such as IP addressing and VLANs are the foundation of a secure network.
SDN Strategies Part 4: Big Switch, Avaya, IBM,VMware
This series on SDN products concludes with a look at Big Switch's updated SDN strategy, VMware NSX, IBM's hybrid approach, and Avaya's focus on virtual network services.
Hot Topics
Converged Infrastructure: 3 Considerations
Bill Kleyman, National Director of Strategy & Innovation, MTM Technologies,  4/16/2014
Heartbleed's Network Effect
Kelly Jackson Higgins, Senior Editor, Dark Reading,  4/16/2014
White Papers
Register for Network Computing Newsletters
Current Issue
Twitter Feed