What does that have to do with Telecom, you ask?
Telecommunication networks are being built in the same manner today as they were built 30 years ago. Years of technological development led by incumbent network vendors evolved the network’s “feeds & speeds” towards growing network usage, while guaranteeing the business justification of these vendors to continuously grow their revenues. On the other side of this equation, the network provided to subscribers was, and still is, consumed using an “all you can eat” model, which is set to maintain the revenue per subscriber and avoid churn. This means service providers must balance a roughly flat revenue curve and a continuously climbing expense curve. An unstable equilibrium, by all means.
How did we get here?
One would ask, if this way of building networks is so wrong, why did we build it this way in the first place? The answer is simple: it was great when it was originally introduced, and it wasn’t all that bad for many years to follow. Back then, the amount of services needed was small, network traffic was still low, consumption model was unidirectional, and unthreatened service providers were ruling the land. Not only this model was good enough, it also practically built empires with ever-increasing capital accumulated over many years. The good “old days.”
Looking at the network today, though, we see that the consumption model has significantly changed over time, and is now completely different. The need for required services exploded, and it has driven data volumes to unexpected highs. Subscribers who are now connected in multiple locations are both feeding and feeding off these services with subscriber-generated content, which is not only pushing traffic in non-traditional directions but also shifting revenue to other service providers. All these changes and more still rely on the same network model which was set to address the needs from the past.
The disadvantages of traditional networks
A traditional network is built in silos: residential vs. business, mobile vs. fixed, packet vs. telephony, and more. Network equipment is built to serve a specific use case or size, with the respective requirements to each situation. Once a new service is introduced, a new network needs to be launched, a new network entry point must be pulled in all the way to the core and back to get access to the service point, Any mix of services needs to happen in the core, and every exhausted resource (e.g., uplink bandwidth) will trigger a painful network update process for service providers.
(An important point to highlight: The first and last points – new network to be launched and a painful update process – are not strokes of bad luck, but rather the actual trajectory of how the network was planned. Bear in mind that this model was set forth in the past by network vendors to continuously increase their revenue flow.)
It’s time to make a difference (i.e., don’t settle!)
Network Cloud (AKA DDC, according to AT&T) was designed and built based on the notion of separating the data plane (bandwidth usage and physical network devices) from the control plane (services and service points). This model, as defined by service providers, is not driven by the desire to buy more equipment upon any change made to the network, but rather by the idea of decoupling network costs from growth and detaching the stronghold that incumbent vendors have today over service providers. Multiple control plane functions can coexist on the same data plane install base, and using standard uniform white boxes connected in a Clos topology fits into any network element size needed.
Looking at today’s requirements and building a solution that is tailored fit to address them is hardly easy, and sometimes an almost impossible task. However, how these requirements have been addressed and resolved is truly visionary. Data and control plane separation allows the control plane to be fully software-based. This level of flexibility maximizes the utilization of network resources (various packet-processing units) and extends the longevity of the network. More importantly, it means that introducing the next service into the network can be selected out of a marketplace catalogue and splashed onto the network at the click of a button. It can run from anywhere to anywhere and folded back as easily as it was launched, with zero truck rolls.
When I present this concept, the responses range from “this is a dream coming true!” to “this is a dream and a dream only!,” but my favorite response is “this sounds too familiar to be called visionary.” A model which separates the function from the hardware it runs on, that clicks new services in and out of deployment, that scales linearly with the addition of COTS boxes, and favors the investment made by the provider has been already widely implemented. It’s called cloud.
It’s time to build networks like cloud
When cloud was first introduced, it was mocked. “Stick to what you know and avoid this passing trend” was the general notion. Some who failed to catch the value of the cloud vanished, while others survived but were left behind, jealously watching what happened to those pioneers who took a step forward, embraced the cloud, and made a difference, and are now ruling the land and the future.
Make a difference and be part of the empire that strikes back.
The network that got you here won't get you there.
DriveNets Network Cloud will.