Leaving things behind is hard, especially when it comes to the technologies with which we are comfortable. Many of us have based our careers, either in part or completely, on maintaining legacy systems. When new capabilities are introduced, some spend an inordinate amount of effort trying to derail things, either intentionally or subconsciously. I personally have been there more times than I care to recall.

However, once I began to accept and embrace the change, I could see the potential for it. It is when you hang onto the past and try to slow down the future that you reach the point where, if you are not careful, you may become more a part of the problem than the solution. In the worse case, you can even marginalize yourself.

That is not to say that all change is for the best. But when due diligence shows it is necessary for business or technical reasons, you reach a point where a decision has to be made. You can no longer avoid the change around you and must accept changing yourself.

Eventually, change is inevitable. Except from vending machines…

But back to the discussions from my last blog… Let's start with the graphic showing the top-level functions of a CCAP. (See Learning From Mistakes.)

Figure 1:

Now let's take that drawing and break it into network layers for L1 (PHY), L2 (MAC), and L3 (routing)…

Figure 2:

I recognize that the delineation between the layers is not that clean, but give me some space to run with this for now. What I am working towards is where the most effective and least disruptive breaks are to show us where we may segment functionality. What I am hoping to show is where this logical segmentation may lead us as we consider distributed access architectures.

Moving layer by layer...
Looking at this from the bottom up, we see that the L1 functions are what we today call a "Remote PHY." This occurs when you pull the physical layer out of the Converged Cable Access Platform (CCAP) core and push it to a remote device, likely in the field collocated with either a fiber node or a cabinet. An interesting point about the L1 functions is that they are typically very hardware-centric due to the modulation and demodulation of signals from a medium. Keep this in mind as we move forward with the discussion.

When we look at L2, this is the constituent MAC functionality that we typically think of as part of the CCAP or CMTS core. Multicast, service flows, quality-of-service, and channel bonding are all functions typically handled by MAC processing. As compared with the L1 functions that are very hardware-centric, many of these functions are software-based and may be possibly run on commercial off-the-shelf (COTS) hardware. Today they are integrated into CCAP, as that is how we built the CMTS from the start.

This monolithic architecture has served us so well for the past 15 years that we are uncomfortable about changing it. If you place them into a separate device, this is what has been termed an "L2 CCAP" or "NR CCAP" (NR stands for non-routing).

Looking at L3, we see more traditional routing functionality. Thinking back to the start of the CMTS era, you may remember that the original CMTS was what we call a Layer 2 device, meaning it did not perform routing. Routing functions were added as we scaled the device and started running into issues with MAC table sizes on the switches and routers connected to the CMTS.

While it has served us well for many years, we are no longer bound by 32,000 or 64,000 MAC address limitations in a switch. These devices are now capable of 1 million or more MAC addresses. There are many good reasons to include routing in the CMTS core, but MAC addresses do not make it a requirement.

Let me get back to the direction of these blogs. Where do SDN and NFV play out in this new CCAP world order? Do they have a place? How can we leverage them to simplify design, enable greater scale in the head-end, and allow us to roll out new services at a greater velocity than we have in the past?

All questions I hope to begin addressing in my next blog. Stay tuned. Same Bat-Time, same Bat-Channel…

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