SDN architectures

Why SDN Matters

Have you spoken with a senior service provider executive lately? If you have, you probably know that in their search for new sources of revenue and cash flow, to quote the old axiom, service providers are stuck between a rock and a hard place.

The rock? Competition for capital. Service providers are typically facilities-based operators, a capital-intensive undertaking if ever there was one. Investment opportunities including datacenters, expansion of fixed-line and wireless networks, and global growth are vacuuming up free cash flow.

Unfortunately, investors in search of safe havens are seeking to tap that very same flow of cash in the form of dividend payments. In our stagnant economy, investor expectations for cash distributions compete directly with service provider product and facility plans for operating capital.

The hard place? Competition for customers who demand service responsiveness at least as good as their daily experience with broadband and consumer-oriented, IP-enabled devices like the iPhone and iPad. As a society, we've grown accustomed to getting what we want when we want it, typically measured in seconds (texting), minutes (online shopping) and days (at-home delivery). These services work so well because they are built on new, cloud-centric systems and tied into wireless networks that have been the focus of billions of dollars of ongoing capital investment.

At the other end of the spectrum is our work experience, which in many cases is decidedly old-school. Salesmen still call, contracts are stacks of paper, service provisioning can take weeks (or months), and service portals take a back seat to investments in fiber and floor space.

Who's stuck in the middle? Service provider customers, IT departments, and product experts each have a chair in this particular purgatory. Customers generally have a good understanding of what they would like to buy, and service provider IT and product teams generally know how to build it, but they are forced to work within a bewildering array of legacy systems that are the result of the past 20 years of acquisitions. In the world of service providers today, even the most minor change is a multi-year, multi-million dollar project, competing with other projects just like it.

This is where software-defined networking (SDN) and network functions virtualization (NFV) come in. To paraphrase Winston Churchill, SDN may not be the beginning of the end for legacy system architectures at service providers, but it has the potential to be a huge step towards a much more responsive and relevant future for core systems.

What does that future look like? I think it has to be a future where systems are engineered for service flexibility, fed by a thriving ecosystem of vendors competing on feature set, not just financial mass, and innovation is enabled, not inhibited by core systems.

With all that said, three things that make SDN important are:

    1. Service flexibility: When it comes to technology naming conventions, most marketing types will tell you that you can't go wrong with a product name that includes "Intelligent" or "Smart," but what customers and service providers really want is a responsive network. The responsive network includes the LAN and WAN, but also all manner of datacenter networking, and ideally, can react to business requirements at the application level. Ideally, an app should be able to express the need for more network resources, those resources should be made available, and a notification and/or bill should be generated. It's smart, but responsive as well, and as SDN and related technologies disaggregate the network stack into a series of programmable interfaces, it also happens to be doable.

    2. Open ecosystem of partners built around standards: We’ve seen the value unlocked by Apple and the Droid community as the app utility has expanded the value of the handset. The negative that proves the point is the Blackberry, crushed for, among other things, only really doing what the phone and a walled garden of apps can do, meaning no app ecosystem, no value extension, no geniuses in garages adding value to your hardware and software. SDN and related technologies could help erode the walled garden that exists around enterprise-class network hardware and software, and create a dynamic marketplace of network-centric apps that survive on their merits, not just whether they can be procured from the network equipment big guys.

    3. Block-oriented architecture for business, not just software: Telcos have lots of problems, but chief among them are multiple legacy systems that are largely in defensive mode… the challenge is to just keep 'em running. If you'd like them enhanced, it's millions of dollars and a minimum of two years. If you'd like them to do something in concert with other legacy systems, it's a "headscratcher" at best, and in today's capital-constrained environments a non-starter. Software companies solved these "enhance and interact" problems years ago by moving to blocks of code, where the individual blocks are written in standard, well-documented programming languages, and interaction between blocks or systems is across well-documented APIs. Now it's time for service providers to apply this logic to entire systems, not just within the systems themselves.

So, SDN is a cool technological approach, but there's a larger strategic point to be made. The promise of SDN, NFV and related initiatives is that in "decoupling the network control from forwarding," they may enable service providers to peel apart the stack of applications that make service providers what they are. In the process, we should end up with new systems that are designed to give equal weight to extensibility (via common languages, tools and documentation), and interaction with other business systems (via standard APIs and service strategy).

— Dennis Brouwer, President, The Brouwer Group

@mbushong 8/22/2013 | 6:17:00 PM
Re: A different position There is some nuance in what people mean when they say "interact". Fine-grained, real-time oscillations of network behavior have been unsuccessful in the past. But the idea that the network ought not know anything about the applications is taking it to the other extreme.

Other luminaries in the networking world like Dave Ward (previously with Juniper and now with Cisco in a CTO role) will tell you that the network can absolutely benefit from knowing more about what applications require.

Intuitively, I don't fully understand the argument against sharing information between the network and application. If you need to do a big data replication job, having the network pre-provision the network makes perfect sense to avoid ccongestion on some links. If you are serving content to a user, knowing where both the content and the user are makes perfect sense, information the network has.

We (IT broadly) even do some of this manually. Hadoop has the notion of rack awareness, but it is statically configured. If you could detect where things are physically located, you could force intelligent VM spawning. 

Suggesting that two things dependent on each other wouldn't benefit from talking to each other seems to go against everything I know to be true in virtually every other discipline. 

Mike Bushong (@mbushong)

sam masud 8/22/2013 | 1:11:31 PM
A different position It's interesting although the author says "an app should be able to express the need for more network resources," some in the industry, including SDN pioneer Martin Casado, question the need for apps to interact with the physical network.
@mbushong 8/22/2013 | 12:19:34 PM
Curious about standards, APIs, and Apple I found the comment curious about standards and APIs, particularly in the context of Apple and Android. The APIs they use are powerful because they are consistent within their ecosystems and developers have open access to them. They are not, however, standard.

As you talk about APIs, is the most important thing that they be standard or that developers of controller applications have open access? Essentially, that they be public.

APIs tend to mirror underlying architectures to some extent, so the idea that different controller (or even device) architectures will be able to support a standard set of APIs seems tough. There might be common protocols (SNMP has provided a fairly ubiquitous interface).

I suspect where we need to see more commonality is higher-lever abstractions. 

-Mike Bushong (@mbushong)

philgr99 8/22/2013 | 12:13:15 PM
Interesting to see how it plays out While I agree with the points you make & fully appreciate the need to change if SPs are going to be able to survive as we know them, it's going to be interesting to see how this manifests itself. Network operators are not going to simply trust the "geniuses in garages adding value to your hardware and software" (I hope!) so testing and certification cycles are going to have to become more rigorous and time consuming. And who is going to support that app five years from now when it's fully embedded in my business but the "genius" who wrote it has retired/disappeared? Adding flexibility for the network owners is great but how will businesses have to change in order to take advantage of it without descending into chaos?     
Carol Wilson 8/22/2013 | 11:51:02 AM
How to get started Dennis, 

Everything you say makes sense - I just wonder how service providers ever dis-engage from their legacy systems to embark on something so new. 

Any thoughts?
Sign In