SDN architectures

Why SDN & NFV Matter to Cable

"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage to move in the opposite direction.” ― E.F. Schumacher

If you have been following my recent columns, you may have noticed a common thread of simplifying things in the service provider network. I have been focusing primarily on the access network, but there are many activities in the metro and backbone networks that have been the focus of standards organizations for years.

As part of my role at Cox Communications Inc. , I have responsibility for the vision of the entire network from backbone to metro, metro to headend, headend to hub, and hub to customer premises. I have the enviable opportunity to craft a holistic view into network simplification.

SDN is one example of how new technologies may be used to simplify what has traditionally been growing larger and more complex. Bigger boxes, more boxes, more power, more rack space, higher-performance components and increased complexity in the network. While SDN is not a new technology, it, along with its kissing cousin NFV, has gained much press these past few years.

I spend quite a bit of time explaining my philosophy of what SDN and NFV are, what they are not and how my team believes they may be used in our network to drive down complexity and cost. While we focus on what SDN and NFV are, we also give consideration to what they are not. We do not see them as the next great technology to rule them all; rather, we see them as other tools that we can use to help build and manage our network infrastructures from end to end. There is no magic in either technology.

Simply put, SDN provides the framework to separate network control and forwarding functions, which allows a programmable control layer and abstraction of the network from applications and services. NFV allows the decomposition of network functions in discrete software components. Two very simple statements that change the very essence of how we view networks. You can find much written and discussed about these technologies and in fact, it is hard to not find an article that does not talk about them as a solution to every network problem known to the human race. I am being an intentional smart aleck, but you get the gist… (See Making Things Simpler.)

SDN and NFV are the latest technology hammers we have and many are using them to take a good whack at every problem, real or imagined. My issue with this approach, as we have seen with each previous latest, greatest, new, improved, tastes-great, less-filling technology, is that it is being applied to many complex issues that in the end may be solved with much simpler solutions.

So, what's my point?

To me, the core issue is that our network is changing around us. We are no longer just broadband Internet service providers. Every device we place in a customer premises either has integrated WiFi or the first device that customers connect to it is a WiFi gateway. Even business customers are doing this behind their routers. We are all looking for ways to create value-added services for our customers to help them solve real, everyday residential and business problems.

At the same time, our competition is deploying new services and technologies at an increasing rate. The bandwidth and complexity growth curve on our network continues to increase, but we do not always realize it. As we are standing on the curve, we find it hard to see what is happening. When you stand on the ground, you don't see the curvature of the Earth; but when you are at a sufficient height, you have the view of what is just over the horizon. We need to challenge our thinking by taking a view from above. What is the real problem we are trying to solve? Does adding this new technology make things easier or more complex? Or, as I said in one of my earlier blogs, "Is the juice worth the squeezing?"

Again, what's the point and, more so, why should we care?

When new architectures are constrained by silicon life cycle, specification writing, development, debugging, regression testing and all the components required when integrating large complex organisms into even larger complex ecosystems, incremental improvements take significant time, resources, money and effort. The more complexity we build into systems, the longer it takes to roll out new services where we actually make money, and the more we burden the new elements with components that have varying development and life cycles that stay with us for a long time. If we can build complex systems from simple components with precise functionality, we can more easily swap out those individual items as new technologies become available, thereby reducing the time to perform integration. I believe that a clearly defined standards-based interface is essential to building the systems of the future.

Simply put, it's not about the hammer or the nail, it's about services… to which end, we will dive into this topic in my next blog. Stay tuned…

— Jeff Finkelstein, Executive Director of Strategic Architecture, Cox Communications

dfoote 10/13/2014 | 2:46:55 PM
Re: Why SDN & NFV Matter Nice article, Jeff.

To your comment . . .

"If we can build complex systems from simple components with precise functionality."

. . . and Gabriel's follow-up comments/question.

I believe the short answer is "yes" but requires some advance, well thought out architecture or platform work.

If the simple components (VNF modules) are interconnected in such a way as to be "tightly coupled", then we may find the same problems and challenges in upgrading or enhancing the total system as we do today with hardware+software tightly coupled integrated systems (i.e. monolithic).

I don't believe the hardest issues to be faced with SDN/NFV will be mostly about "thick/heavy" or "thin" modules.  I think it will be about a how to do modularity supporting upgrades (changing modules) or additions/deletions dynamically (system isn't disrupted when any module is changed or added/deleted).

Making complex software systems out of modular components has been done for awhile now in the IT world.  But to accomplish that in such a fashion as to avoid the concern's Jeff raises requires putting in place a software architecture, from day one, that supports dynamically changing (upgrading, adding, deleting, moving, etc.) software modules without disrupting the whole system.

For example, Open Daylight uses Java/OSGi modularity to achieve these goals.  And web services platforms like Weblogic and Glassfish have similar dynamic modularity capabilities.  By defining the "rules of the game" for modularity day one, developers then have a structured methodology for making dynamic, modular, large scale, complex systems out of simple components.  

Those are just some examples of how it can be done.  But those examples are for a "single system" (i.e. multiple modules but typically operating on the same VM or address space).  With NFV, the challenge expands because VNFs will be deployed across different VMs, OS instances and/or physical hardware in different geographic locations as well.  

In my mind, that is the more challenging aspect of NFV than whether to make a particular VNF "thick" or "thin".  In fact, the advantage of a well-thought out, day-one modularity platform is that the developer(s) of the system don't necessarily have to get it just right the first time around.  A thick VNF can be implemented and then as behavior and performance is analyzed, if it makes sense, it can be broken down into multiple thinner VNFs later on (or vice versa).

And the more interesting and exciting end game, is the potential ability to add new VNFs in the future that no one has yet conceived of.  And the larger system can then discover the VNF, determine valid interconnect and then activate into the behavior of the larger system.
melao2 10/13/2014 | 2:31:53 PM
Network Assurance I do see the benefits for network simplification and service provisioning in SDN/NFV.

But I still have doubts about network assurance. How would it work since we would be "centralizing the intelligence" in the networks? 

Nowadays, the network is resilient to failures due to protocols that run in the box. It is completely autonomous from the any centralized controller. In that respect, when there is an outage the network itself can restore the services using the protocols in those boxes.

When you remove such intelligence from the network boxes, if there is a network outage and let's say the box looses the communication to the centralized intelligence (namely SDN controller), how would these networks be resilient?
jlfinkels 10/13/2014 | 9:39:49 AM
Re: Why SDN & NFV Matter Thanks for the response. Some thoughts...


Not sure what you mean by "thin" or "fit". I think of VNF as heavy and lightweight. The more functions the heavier it is. Thinking in terms of UNIX processes, a thread would be lightweight, a process would be heavy and a VM would be very heavy. I don't think VMs are the answer, instead I want things as lightweight as possible with simple gozinta's and gozoutas's. It makes them much easier to replace in the long term.

I think of simpler in terms of adding new funtionality. Today we need to build hardware or monolithic software to make a change. When we can replace a single lightweight VNF it reduces the complexity of the overall ecosystem to handle the integration and regression testing. That would be a good thing.

It changes the paradigm from the silicon cycle to the software agility cycle. A completely different way of thinking about adding features.
Gabriel Brown 10/13/2014 | 9:14:56 AM
Why SDN & NFV Matter A good column. Thanks.

I'd be interested in people's thoughts on how application (VNF) design changes in view of these two statements:

 "NFV allows the decomposition of network functions in discrete software components."

 "If we can build complex systems from simple components with precise functionality."

One of the areas I'm looking at (for Heavy Reading) is the idea of the "Thin" or "Fit" VNF. Candidly, I don't have a good definition yet, but it is a more substantial change than stripping the unnecessary software modules from existing applications (e.g. chassis managers) and porting them to VMs.

Quite how this makes things simpler is not entirely clear either...
Sign In