There is probably no issue more important to the future of networking than the union of networks and hosting. It may seem that’s a simple one; we have the Internet and the stuff that’s on it (including the cloud) and the stuff that’s in it are working globally at significant scale. In fact, though, that’s one of the things that makes the problem a lot less than simple.
Networks, including the Internet, have an “outside” and an “inside”. In the old days of TCP/IP, when the Internet was young and people could assume everyone was “of good will”, these two dimensions were really one. You could address routers as easily as addressing users or servers. Over time, it became clear that everyone wasn’t of good will, and we started to see protective barriers erected between components of Internet infrastructure and the “service layer” of the Internet, the public or outside space. Companies who built their own IP networks with trunks and private routers shifted to virtual private network services, and that created another layer.
The virtual private network or VPN is a significant step, for reasons beyond the business level, because it formally introduces the notion of virtual networks. A “real” network is made up of routers and trunks, but a virtual network is some sort of overlay on that real network, an overlay that creates a semi-autonomous community of connectivity. Virtual networks proved critical in cloud computing because they allow a cloud provider to create tenant networks that are independent of each other, something that’s critical for security.
Security is a key point here in our fusion of networking and hosting. If we have a “virtual network function” or VNF that’s part of Service A, we not only have to ensure that Service B can’t access it, but also that Service B has only minimal ability to impact it. If our VNFs are hosted on a pool of resources, we also have to ask whether the deployment of VNFs can be allowed to “see” those resources, because if they can they can impact all services.
What we end up with, addressing these constraints, is a model of networking that has three logical layers. The top layer is the service layer, which is what users of the network see. The bottom layer is the network that controls the pool of resources on which functions are hosted, and the middle layer is a tenant-service-specific layer that contains pool resources that are assigned to a specific service mission. All these network layers are virtual, all are independent. When you decide that you’re going to build a service from virtual functions, you need to have those functions hosted at the bottom and organized in the middle.
Where virtual functions represent what are essentially on-network features, such as the layer that mobile networks call the “control plane” (in contrast to the “user plane” which is the entire IP stack), the network itself treats them as users rather than service components, and that makes things pretty easy. The problem is more complex when the VNFs are actually service elements, meaning that they are virtual forms of real, traditional, network devices.
A VNF in that mission lives in three worlds. First, it lives (at least potentially) in the service network, because it often presents an interface that’s addressable by service users. Second, it lives at the server pool level, because it runs on a server, VM, or container host and has to be deployed and managed there. Third, it lives in that elusive middle virtual layer, because its relationship to other elements has to be separated in network access terms, from what’s above and what’s below. How this happens could vary, but for simplicity let’s abstract the approaches into a single model.
You start with a server resource pool, and that pool has a set of network addresses that form our bottom virtual network. That virtual network is accessible only to the people running the server farm. Its management properties are invisible to the layers above. This pool might be contained in a single data center, or multiple data centers, but its structure is visible only to that lowest virtual network.
When you want to create services, you deploy, on that lowest virtual network, a series of software components (“VN adapters”) that have the ability to support multi-tenant middle-layer virtual networks. Elements of each of the tenant-virtual-networks are deployed on the bottom layer and their connectivity is confined within the tenant network. That network cannot “see” the bottom layer, nor can one tenant see the other. Furthermore, it is totally invisible at the service network level. Connections can be created on the tenant network to link the VNFs deployed within it.
The final step here is to expose some interfaces of the tenant network to the service network. This is essentially another of those VN adapters, one that provides an address proxy and other features as needed to present the interface to the service network. It can then see these interfaces, but no others.
Each of the virtual networks could have its own protocols and rules, but in nearly all cases these networks will be IP-based. They will have an address space, and other than the service network which almost surely will use public, assigned, IP addresses as the Internet does, they could use either a public or private IP address space. If dynamic address assignment is needed, they would have to contain a DHCP server, and if they wanted to decode URLs they’d need a DNS server as well. In addition, the VN adapters might have to spoof some IP control packets; you don’t want a ping or traceroute to find real components, and in any event they would likely not be addressable.
OK, this is an abstract model, but what might a real implementation look like? That’s where things get potentially more complicated, but I think we could state a principle here that could lead to simplification. The architecture for deploying virtual functions should be the same as that used to deploy application components in the cloud. The NFV ISG process of 2013 made a fundamental mistake by not linking NFV to the main thrust of cloud computing. Because some virtual functions (mobile network control plane, as previously noted) are “on the network” like any cloud application, we could expect them to deploy that way. Because edge computing is likely to generate new services and features that will include what are really application components, it should use the cloud model too.
The prevailing cloud technology for deployment and redeployment is containers and Kubernetes. Kubernetes has the virtual networking capabilities (via virtual network add-on support) I cited here in my abstract model. Logically it should be the choice for the framework that we use to bind networks and hosting for the creation of VNF-based service features. This, of course, is the goal of the Nephio project that Google launched, and one I hope will define the space in the future.
We can’t just wave our arms and declare the problem solved by Kubernetes or even by Nephio. To address the whole picture, we have to step beyond, or around, the cloud. There are other issues to be considered, and I’ll look at them in other blogs down the line.