Over the years, we’ve had many different protocols, but the interesting truth is that within each of them, there’s a common element—the data. Whether we’re transporting information in IP or SNA or DECnet or X.25, we’re still transporting information. The protocol isn’t the information, it’s just a contextual wrapper that defines the rules for exchanging the information successfully. If we accept that, then we have the beginnings of a truth about the way future networks might be built.
Let’s start with a reality check here. Nobody is trying to get rid of IP or the Internet, as they exist as end-user services. What they’d love to refine, or even get rid of, is the baggage associated with IP and router networks. If you look at how IP has evolved, it’s hard not to think of it as being a very long way around the track to repurpose a protocol for stuff that was never even considered when the protocol was designed. What we do with IP today is deliver multimedia content, support mobile users, and neither mission really existed back in the days when the protocol was invented. The thing is, everything in a commercially useful sense that consumes data today is an IP device. We have to do whatever we do to networks without impacting what uses the networks.
IP as an interface isn’t the same thing as IP as a protocol, and that’s not the same thing as IP as a network architecture. IP networks are built with routers, which are purpose-built devices that talk not only the user IP interface but also “internal” interfaces that include features not made visible to the user at all. One big problem with this model is that it’s difficult to advance features quickly or incrementally because the routers have to be upgraded to do it.
One of the big areas where network operators want to add features is in the area of traffic engineering. Another is in fault recovery. Both these were drivers behind the original concept of software-defined networking, and SDN started with the presumption that we’d accomplish IP advances by first separating the control and data planes. The data plane would carry only end-to-end information, and all the rest would be pulled out and handled “over top of” the data plane. Today, we’d say that “the cloud” would handle it, but in the original SDN approach (still the official one) it’s handled by an SDN controller.
A lot of people would say that a control plane in the cloud isn’t much of a leap beyond the centralized (and vulnerable) SDN controller concept, and that could be true. “Could be” depending on how the concept is implemented. Recall that I blogged a bit ago about “locality” as opposed to “edge” in considering the placement of computing resources. A few people on LinkedIn have also noted that separating the control plane by simply hosting it somewhere on a potentially vastly distributed set of servers might not be optimal in terms of latency or stability. I agree; there has to be a new way of thinking about the cloud if you’re going to deploy the IP control plane there.
In my blogs on the topic (especially the one referenced above), I noted that the missing ingredient in “telco-oriented” cloud computing was the notion of “locality”, meaning that some microfeatures had to be hosted proximate to the point of activity they served. Something supporting Interface A on Device B has to be close to where that happens to be, if the “support” is expected to be near-real-time. A randomly chosen resource location could be a disaster.
It follows, though, that if you’re actually going to have a “cloud” at all, you have to pull the microfeature-hosting resources from the device and place them nearby. It would also be logical to assume that the operation of a control plane, especially the supercontrol-plane that I postulated as a combination of all service-coordinating features, would include microfeatures that wouldn’t be as latency sensitive. Thus, we’d need to be able to ask for resources proximate to the point of activity but not joined at the hip to it, so to speak.
The point here is that “separating the control plane” and “virtualizing the control plane” aren’t the same thing. If control planes did nothing beyond what IP itself requires, you could see that the implementation of a cloud-hosted control plane would likely involve a kind of local interface process set, resident with the interface in some way, and a topology-and-management process set that would be distributed. The where and how of the distribution would depend on the implementation, which means that we’d need to think about how this new supercontrol-plane got implemented in order to decide where the microfeatures that make it up could be placed.
From what Google has said about its use of this approach in its B4 background, we can infer that Google saw separating control and data planes at least in part as a means of simplifying what goes on with IP, MPLS, and optical networking. Each of these has its own control plane, and in a traditional large-scale application of router networks, each would be part of a layer stack in the order I referenced them. Google, in B4 itself, didn’t integrate higher-layer services into the picture, because B4 was an IP backbone. In the broader Andromeda application, which includes Google’s B2 interprocess network, they do network microfeatures directly. The relationship, if any, between these two isn’t specified.
That may not be the best way to approach a commercial solution to optimizing the separate and supercontrol-plane concepts. For that goal, it would be best to either integrate commercial tools (Kubernetes, Istio) to create a microfeature framework, enhanced to support locality, or to create a high-efficiency version of the two for specialized network microfeature applications. This would be best done by integrating it with the architecture that separates the control plane in the first place, meaning the emulation of IP networking.
The role of B4 in flattening the IP, MPLS, and optical layers is an interesting topic in itself. We’ve tended to treat layers as not only inevitable but mandatory since they came along with OSI in 1974, but that was then and this is now. Is a layered approach really the best way to run networks today? For example, if we have dynamic optical connectivity and dynamic connectivity at Level 2 or 3 or both, and if we have “control-plane” processes that can manipulate features at all the levels, are we really looking at layers in the OSI sense? Are all the higher layers of the OSI models now subsumed into a supercontrol-plane approach? That seems to be the goal of B4.
It may seem a radical thought, but it’s very possible that we’ve outlived the usefulness of layered protocols. While the OSI model defined seven layers, those layers are divided into two “zones”, one (Level 1-3) representing the connection network and the other (4-7) the application relationship, meaning end-to-end. We’ve seen the world focus its attention on IP-based connection services in the first zone, and we’ve seen the second zone compressed by things like 3GPP specifications, which create an interface point between a “network” and a “service”, meaning between the two zones. In both cases, the specifics of the zones themselves seem to be getting lost. Maybe, in fact, the zones themselves are starting to mingle.
What I think is happening is that we’re entering (perhaps unwittingly) the age of network-as-a-service, and what NaaS is a service to is applications, meaning software. For those who need an OSI lesson, the Application Layer was the 7th of those OSI layers, the top of the stack. If NaaS presents a Level 7 interface to applications, then the entire OSI stack is subducted, invisible. Present the right API at the NaaS top, and Tinker Bell can carry packets on little silver wings for all we care (as long as she can meet the SLA).
NaaS, as a conception of delivered services, could free network infrastructure from strict conformance to IP behavior, even if the service delivery is made in an IP envelope. Networks composed from microfeatures can have a variety of internal properties as long as they present the proper NaaS interface(s) at the top. Are some of the challenges we have in network virtualization due to the fact that, by “virtualizing” router networks, we’re also codifying routers?
For service providers, network operators, NaaS could be a windfall. The absorption of higher-layer features into “network” services lets them climb the value chain via a familiar ladder. Connectivity is expanded to include application-specific elements—4G and 5G mobility-to-data-plane interfaces, CDN, data center interconnect, IoT services, you name it. If the “service” serves applications directly, then a lot of application features that would benefit from as-a-service implementation can be absorbed into the service. This might be the pathway to new revenue that avoids direct collision with the current cloud providers and OTTs.
Again, this doesn’t mean the death of IP, because network connections still require network services, but it does mean that the network could become (as I’d argue it has for Google Andromeda) almost a byproduct of a microfeature-connection architecture, an architecture that isn’t protocol-specific, but interface-defined. I think that things like SD-WAN, SDN, and Andromeda are leading us in that direction, and I think that a shift of that sort could be the most radical change in networking that’s ever been considered.
It could also be fun; many of those who fought the transition from TDM to packet would have to admit that their lives have gotten more interesting under IP, in large part because IP is less constraining to applications. NaaS could remove all constraints, both to applications, and perhaps to fun as well.