For those who have been hanging in for the past few months, much thanks. Light Reading has been kind enough to post my musings on various technologies from meeting behavior, to DOCSIS, to SDN and NFV. What I hope to do for the next few blog postings is to focus on the "whys" of SDN and NFV for cable.
First, let me go back to my five simple technology rules that I often bring up with my teams (and honestly anyone who will listen). I try to keep bumper pads for technology to help my teams find some directional guidance, but without getting in their way as they look for new technology applications to improve our customers' experience and also in our business as a service provider.
Hopefully these are easy to understand and direct…
1. Simple, modular architectures always win
2. Centralize what you can, distribute what you must
3. Silicon matters for scale, availability and resilience
4. Automate anything that can be automated
5. Support open standards
My plan is to address each one individually in an article over the next few months. Specifically, I want to address how some of my 5SRs ("5 Simple Rules") can be applied to SDN and NFV. Please stay with me for a few moments… (See Why SDN & NFV Matter to Cable .)
I don't know about you, but personally I am a bit worn out by the hype around SDN and NFV. It seems to be front and center in every telecom publication, article and conference. What I have not seen is much discussion about is where you should and should not use it. No technology is perfect and it is the act of focusing on technology and not on the business problems which makes us tired of things that may help in the long run. Remember last month's blog's mantra? It's not about the hammer or the nail, it's about services…
Applying my 5 Simple Rules to SDN and NFV, I see ways we can break these technologies down to bite-sized chunks. Let's start this time from the top and work down...
Rule #1: Simple, modular architectures always win
This has been true for as long as I can recall. We constantly try to prove it wrong but in the end we go right back to it. Think about it. For computer hardware, we have IBM mainframe to VAX super minis, VAX super minis to personal computers, PCs to laptops, laptops to smartphones, large complex programs to ones with functions or subroutines, later to small distributed ones, etc.
Or as it pertains to the cable business; integrated CMTS to modular CMTS, integrated CCAP to remote PHY/remote MAC PHY/distributed architectures. Even in telecom, there are discussions of remote architectures for PON.
I first looked at this phenomenon and thought "Duh, of course we want to do that. We can now scale the individual components separately." I didn't understand why everyone didn't see it that way.
Now that I've thought about it more, I realize that there is an even more important reason to go with simple, modular architectures. And it has nothing to do with scale, but instead has to do with technology life-cycles.
Think about it for a few moments… We can not only create the ability to scale components separately but we can keep technologies with different life-cycles from affecting each other.
I realized this when I started looking into WiFi and DOCSIS performance. We are in the throes of the gigabit experience. However, very few devices in the home can actually achieve gigabit-per-second speeds due to limitations of WiFi networks, operating system constraints, processor performance for handling each packet while doing other work, etc. Yet we continue to push these gigabit speeds because of competitive concerns.
We have at minimum two diverse technologies in most home termination equipment. We have the DOCSIS modem or PON ONT, which advance at a snail's pace in this technology-consuming world. Standards bodies, industry consortiums like CableLabs and FSAN, system vendors, service providers and silicon manufacturers all have input and drive these technologies. The same is true for WiFi under IEEE.
Yet, WiFi advances are taking place two to three times faster than other access technologies. There are a variety of reasons, but in my humble opinion it is because we are still in the early stages of this technology's life cycle. There are typically rapid advances early on in the technology curve that slows down between disruptive technological shifts (think BPON to GPON to NGPON2, or DOCSIS 1.0 to 3.1). It would be interesting to hear others' views on this.
With WiFi changing at a much more rapid pace than DOCSIS or PON, why do we continue to burden equipment we place into the customer premises with older technologies for two to three times longer life-cycles than the faster-paced technology? Separate the technologies with different advancement cycles and you can now replace them independent of each other.
Makes sense in retrospect. Well, maybe not to everyone…
Stay tuned for the next article when we discuss centralized vs distributed…
— Jeff Finkelstein, Executive Director of Strategic Architecture, Cox Communications