It should be obvious that carrier cloud needs a network. Perhaps it is, but if so there are plenty of network operators who haven’t really considered what that network would be, where they’d get it, or how the choice might impact their overall success in transformation. We’ve come a long way down the line of hosting network features in carrier cloud without proper concern for this critical issue, so it’s time to take it on.
IP networking overall creates a flat, universal, address space that we call “the Internet” but that’s actually made up of a series of assigned IP address ranges. The “public” IP addresses can be used by their owners to join in the Internet community or to create a virtual private network (VPN). The dominant IP addressing model today is IPv4, and we’ve already got more things on the Internet than IPv4 can directly address. One obvious solution to that is to adopt the new IPv6 model, which creates a much larger (IPv6 supports ten to the 28th power addresses, more than we’re likely to need), but IPv6 has been around for a decade and it’s still not the dominant model.
What’s saved us from IPv4 limitations so far are two concepts—“private” IP addresses and network address translation (NAT). The IETF assigned three ranges of addresses (a Class A range, a B range and a C range) that could be used internally but not sent out onto the Internet, since they are not assigned to an owner and are thus not unique. The NAT process lets devices that can generate an Internet query but can’t be reached as an open resource generate a “stack” of addresses, one being the inside private address of the device and the other the outer “public” address of the gateway to the Internet. Since most Internet growth has been in this type of request-only device (you can send a response to a NAT request, but you can’t originate a connection to a device with no public address), this has taken the heat off the IPv4 space.
The reason I’m going into this is that these same private IP addresses are widely used in application deployment. Multi-component applications typically have a bunch of internal connections to pass work among the components, and a very few connections open to the outside world. In the typical OpenStack and Kubernetes models, a private address space is assigned to an application, and the public APIs the applications need exposed are then translated to a public address. Not only does this save on IP addresses, it also means that the application components that should never be addressed from the outside don’t have an outside address to reference.
Cloud computing also stimulated the concept of “virtual networking”, which is a form of networking that creates an overlay of some sort on top of IP. This layer forms something like the private IP addresses do, except that there’s no theoretical limit on the size of a virtual network address space or what can connect with what. Public IP and NAT create IP-sanctioned partitioning of applications (or service features), and virtual networks create IP-independent partitioning.
Network operators today recognize two primary sources for virtual-network solutions. One is VMware, whose NSX is based on the Nicira acquisition that represented the first virtual or “software-defined” networking product. The other is Nokia, who acquired the Nuage virtual networking product.
The beauty of these virtual-network solutions is that that IP-independence property I mentioned. When you build an application, you’re building it within your infrastructure. You’re used to applying access control to keep out unauthorized users, and you don’t expect that your data center network itself is partitioned. That’s not workable for a cloud provider for security reasons. Every tenant, meaning every user and perhaps every application, has to be separated. That’s what gave rise to the virtual-network thing in the first place, and it remains the critical property. If you can separate tenants with a virtual network, you can provide a secure hosting framework shared by many. That’s true whether you’re providing public cloud services or providing feature hosting for an enterprise private service like a VPN, or a public voice/data service like 5G.
SD-WAN is another example of a virtual network. Technology varies, but overall SD-WAN implementations provide a form of an overlay, which means that they can ride on top of IP connectivity. They are not typically used to separate tenants in a data center, though. However, both VMware and Nokia offer SD-WAN features on their virtual networks, which means that there are at least two providers who specifically merge multi-tenant data center networking and SD-WAN.
In a carrier cloud, you could see a variety of virtual-network approaches, even several of them at the same time. You could use a virtual network for tenant isolation and overlay a public/private IP network model so you could take advantage of all the cloud application tools designed for that model. You could use a virtual network for everything. You could add an SD-WAN to a service built on a combination of virtual networks and public/private IP. Name your choice, and someone could probably come up with a reason it might be useful. But “every possible combination of network technology” is not an efficient approach to building carrier cloud or its services. Some cohesive approach would be better.
The big complication in carrier cloud is the multiplistic nature of monitoring and management. Think of Big Customer, an enterprise client. They have four different services, all of which have some features hosted in Big Telco’s carrier cloud. Each of the services should be deployed to ensure that their network service access point (NSAP) interfaces are addressable by the customer, and a suitable network management interface should also be exposed for the services. Each of the services should be fully visible to the operator, obviously, so they can be deployed and managed. Finally, all of the services may share some elements, so it might be necessary to make some of the service APIs that are not customer-visible visible to other components of those four services. That’s a lot of specificity, and getting it demands a plan.
Here’s an example of one. Every service is a unique “service subnet”. That subnet exposes a set of APIs that must be customer-visible to make the service useful. It also exposes a set of APIs (which might include some of the same ones) onto a “customer subnet” to facilitate sharing of resources at the customer level. Finally, it exposes a set of APIs onto an “operator subnet” that provides a connection to carrier cloud orchestration, monitoring, and management. What we need is a way to map these “subnets” to some sort of virtual-network or public/private IP network approach, so we know how everything has to be connected and can keep those connections intact through scaling, redeployment, and service changes.
Some overall carrier-cloud virtual-network approach is essential, or there’s a major risk that all the pieces of carrier cloud won’t come together. Yet where is the planning at this level? Have operators picked an approach? Not according to the operators. We seem to forget that the dynamism, the elasticity, the scalability of the cloud and virtualization can’t be met if we tie elastic hosting to rigid networking.
This isn’t the only issue that’s hampering progress in carrier cloud, NFV, and even SDN. Over the next week, I hope to look at a couple other issues that will in some cases illustrate why we need virtual networking, and in other cases illustrate why we need to think through the whole concept of virtualization more carefully.