If we can build complex systems from simple components with precise functionality, we can more easily change those systems as new technologies arise.

Jeff Finkelstein

October 13, 2014

4 Min Read
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

About the Author(s)

Jeff Finkelstein

Jeff Finkelstein is the Executive Director of Network Architecture at Cox Communications in Atlanta, Georgia. He has been part of the engineering and architecture groups at Cox since 2002, and was part of the team responsible for the deployment of DOCSIS technologies, from DOCSIS 1.1 to DOCSIS 3.0. Jeff has made significant contributions to the access network design and deployments at Cox, and has the new role of being responsible for future technology planning of backbone, metro, edge, access, and home networks. He is now part of the CableLabs DOCSIS 3.1 PHY and MAC teams, in addition to being part of the IEEE EPOC specification effort.

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like