The separation between control and data planes is a pretty-well-accepted concept, but one complicating factor in the picture is that the term “control plane” isn’t used consistently. Originally, the “control plane” was the set of protocol messages used to control data exchanges, and so it was (as an example) a reference to the in-band exchanges that are used in IP networks for topology and status updates. With the advent of more complex services, including 5G, the term “control plane” references the exchanges that manage the mobile network and infrastructure, riding above the “user plane”, which is now the IP network and thus includes the data plane and the old control plane!
About a year ago, I did a presentation to some operators that used a slide that defined four layers of a network. I put the data plane at the bottom, the control plane next, and then the service plane, which I said was a better name for the layer of signaling that mediates IP data flows, the lower two layers. At the top of it all, I sat the experience plane, which provides the actual experiences that users of a network are seeking—video, websites, etc.
We actually have examples of things in each of these four areas today, and the way the planes relate to each other and to the user is important in understanding the best approach to defining future network architectures and infrastructure. However, as soon as you start looking at that problem, you confront yet another “plane” that runs vertically along all these horizontal layers. That’s the virtualization plane, and it contains the signaling that manages whatever hosting and deployment processes are used to realize the functionality of the other planes on a cloud infrastructure.
When we talk about things like 5G, we’re dealing mostly with service functions, and so we’re dealing mostly with things that live in the three lower planes. My experience plane is relevant to 5G only in the sense that the things in it are part of the public data network that 5G user plane activity is connecting with. The specs don’t define how we actually achieve virtualization, except through reference to NFV, which actually does a pretty poor job of defining the way we’d want to deploy and manage functional components in any of those planes.
You can see a bit of this, by inference, in my blog about Ericsson’s complaints about Open RAN security. Since we’re not dealing with the actual mechanisms of virtualization in an effective way, there are indeed potential security issues that emerge. Not just with Open RAN (as I noted), though. All of the network planes have the potential for security issues at the functional level (a function could be compromised), and to the extent that they interconnect elements or virtualize them, they also present security risks at the implementation level, meaning an attack on infrastructure or the orchestration and management interfaces.
The special challenge of virtualization, meaning the replacement of fixed appliances like routers or firewalls by hosted features (single features or chains or combinations thereof) that do the same thing, is that we’ve exposed a lot of additional stuff that not only has to be secure, but has to be somehow created and managed without generating a lot of operations burden.
This is why I’ve always liked the notion of “fractal service assembly” or “intent modeling”. If we presumed that a given feature or function was represented by a functional abstraction linked to an opaque (black-box) implementation, and if we could make the resulting model enforce its own SLA within the black box, then the complexities of implementation are separated from the functional vision of the service. Since that vision is what users of the service are paying for, that creates a level where service provider and service consumer speak the same (functional) language, and the devilish details are hidden in those black boxes.
One of the advantages of the black-box approach is that creating an abstraction called (for example) “Router-Element” with the same interfaces and management APIs as a real router would let you map those 1:1 to a real router. Before you say “So what?”, the point is that you could map any software instance of a router, any SDN implementation of a router, or any collection of all of the above that did routing, all to that abstraction. You now have an evolution strategy, but this isn’t the topic of this blog, so let’s move ono.
The relevant advantage is that we now have, because the implementation of what’s inside the black box is opaque, a unit of functionality that doesn’t assert any of the interfaces or APIs that the implementation (versus the functionality) requires. We can contain the scope of the internal service and control plane layers of my model. We can also now define a virtualization-plane process that operates only on the functions. Inside the black boxes there may be virtualization, but it’s invisible. This is what fractal service assembly is about. You divide things up, make each thing opaque and autonomous, and then deal with a network of things and not one of specific technologies.
If the service plane, then, deals with “thing networks”, it becomes independent of the implementation of the things. We can build services without worrying about implementations. We can, by asserting proper interfaces from the data and control planes into the service plane, construct service interfaces for 5G’s “control plane” to consume. Our black-box service plane is then the 5G user plane, and our service plane has a layer that creates the proper 5G interfaces, then defines the 5G processes that consume them. Those, like our lower level, can be functional black boxes that hide the implementation.
This is the important point here, the conclusion I’m aiming for. Every layer in our approach is a black box to the layers above, just like the OSI model mandated in 1974. We have to define the binding interfaces between layers, represent them as intent-modeled interfaces, and then focus on how to implement the inside of those black boxes, both in terms of current technology and in terms of the various visions of the future. The approaches that can do that will save us, and the others will be simply more marketing pap for the masses.
