It’s the Data Plane, Stupid!

So why am I writing about a concept that is not new, and stating a somehow obvious observation regarding the difference between the control and data planes?

What is the difference between the control and data planes – Isn’t that a good question?

It’s actually pretty straightforward: when it comes to network disaggregation, in any network domain and for any technology, this difference becomes extremely important.

Take, for example, two recent announcements:

• AT&T outsources its 5G core network to Microsoft Azure cloud service
• DISH plans to run significant parts of its new 5G network over the AWS infrastructure

While those two examples have technology (5G) and region (North America) in common, I believe they highlight a significant evolutionary trend in the telecom industry. Operators are now focusing on their service offering, while offloading to 3^rd parties any part of their network and operations that is generic enough to be implemented over a cloud infrastructure.

This is not the first kind of “commoditized” infrastructure component that is being offloaded by telecom operators. Other examples are data centers (e.g. Verizon’s data center move with Equinix) and tower infrastructure (such as T-Mobile’s deal with Crown Castle).

Wait, is there a difference between selling data centers or wireless towers and outsourcing network functions?

Yes, there is a major difference. While data centers and wireless towers are, at the end of the day, sell-and-lease-back real-estate deals, network functions hold significant meaning to the telecom industry.

Cloud service providers are becoming much more than, well, providers of cloud services. They are becoming a new type of “carrier of carriers” (or alternative access vendors – AAVs) and, in some cases (like Microsoft’s moves with Affirmed Networks and Metaswitch Networks), becoming even an alternative to telecom infrastructure vendors.

So what’s the next step?

When taking such a move, operators should refresh their CUPS understanding and go back to the basics of their network planning. And this brings us back to the fundamental difference between the control plane and the data plane.

While the control plane does not carry a significant amount of traffic, it does require a substantial amount of compute resources. This becomes even more critical as the number of network connections grow (and grow they do, driven by IoT services such as mMTC and Industry 4.0).

The data plane, on the other hand, requires lower compute resources (as CUPS leaves it with very little “brains”) and lots and lots of networking resources.

Lots and lots of networking resources?  That doesn’t sound good…

No, it doesn’t – there lies the catch. Moving network functions into a public (or private, or hybrid) cloud makes perfect sense when it comes to the control plane, as the cloud provides just that – compute (and storage) resources. When it comes to the data plane, though, running such functions over a compute-centric infrastructure (which could be a CNF over the cloud or VNF over a server) simply does not scale.

You may argue that this is not the operator’s issue as it buys a service from the cloud service provider. But, at the end of the day, there is no such thing as a free meal. If the cloud service provider needs to invest heavily in servers that run I/O tasks for which they are not optimized, the telecom operator will not remain unaffected.

Is there a solution for running the data plane over a cloud-native platform?

The answer is – yes! It just needs to be a networking-optimized cloud platform – DriveNets Network Cloud, in short.