It’s been about 30 years since it became clear that Internet Protocol (IP) was going to take over as the foundation for the network of the future. When we’re talking “future,” though, it seems a little dated to focus on something 30 years or more in the past. There’s been talk about a new approach to networking, a new network model, for at least a decade now. But is anything happening? Several factors and the future of networking probably rests somewhere in the mix.
One thing that seems almost certain to be a piece of our network future is the “white box.” Network devices today are usually provided by vendors who create a monolithic combination of software and hardware. You build networks with capital projects, meaning that those combination boxes have to depreciate over time (five years is a common period). If you decide you’d like to change, you face writing down any unrealized depreciation as part of your project cost, which can make changing your vendor financially impossible.
White boxes limit lock-in risks in two ways. First, they’re cheaper to start with (between 50% and 70% the price of a proprietary router), so there’s less to write off if you change your approach. Second, you can run a large variety of network software offerings on the same device. Since software functionality is the key to network functionality, that reduces the chance that you’d have to change out those devices in the first place. Win-win.
All’s not beer and roses here, though. There are two basic approaches to software portability on white boxes. One is to use the white boxes as forwarding devices based on the Open Networking Foundation (ONF’s) OpenFlow protocol. This relies on a central controller to manage the forwarding processes, but nearly every white-box device can support OpenFlow. The other relies on an open network operating system on the switches, which can then support any network software that operating system (OS) supports. The risk in the latter approach is custom chips.
It’s fairly easy to find a network operating system (NOS) that runs on a generic no-special-chips white box. But when specialized silicon is used for high-speed packet forwarding, the chips have their own control language to accommodate. I propose you do that by supporting the P4 flow-programming language, as chips and software that support P4 are very interchangeable. The problem is that everyone doesn’t support P4. That may make the first, OpenFlow-based, approach more useful in the near-term.
In the longer-term, there’s another bigger issue to consider. For a decade, people have talked about “separating the control plane from the data plane” in IP networks. The ONF SDN specifications describe an SDN Controller that manages all of the forwarding tables in all the OpenFlow-equipped switches. That controller defines a set of APIs that would allow applications to control forwarding directly, which could be a true game-changer.
Mobile networking is an example of a place where this capability could be valuable. Mobility management elements of both 4G and 5G use tunneling to create a virtual-network path, over IP, between a public network (the Internet) and a user who might be roaming across multiple cells. Could 4G/5G interact with the SDN controller to directly establish those paths, with no tunnel overhead? The same capability could benefit content delivery networks, improving video handling.
The problem with the SDN controller approach is that nobody has been happy with the idea of a single giant chunk of software that runs the network. There are issues with a single point of failure, as well as what happens if the controller is overloaded. There are also problems with what might happen if an OpenFlow switch was cut off from the controller by a fault and could then not be updated to rejoin.
The solution to these problems is to implement a logically centralized but functionally distributed control plane. Build a control plane of cloud-hosted microservices, and you could scale features and services using cloud capabilities. The ONF hasn’t gotten to this point yet, but that’s the approach Google has been taking for years with its own network architecture, Andromeda.
Andromeda is a virtual-network, virtual-function architecture that combines the best of SDN and the ETSI Network Functions Virtualization (NFV) project. Unlike SDN, it’s based on redundant controllers that are “federated” with each other to create scalable networks. Also, it’s designed to connect cloud-native “microfeatures” that can be categorized into services and applications. Google uses this for its own backbone network, both for the search and content services and for Google Cloud.
Could Google compose an SDN controller and eliminate the whole concept of a central (even if it’s redundant) controller? I think they could. Could someone else take that step? I think that’s also true, and that raises an even more intriguing concept—a kind of multi-service control plane.
5G thinks its mobility management is controlling the network, and so does IP’s control plane and adaptive routing. We have a half-dozen proposals out there for the enhancement of IP to improve traffic engineering and support new services. Suppose that we had a kind of “naked forwarding plane” with no protocol at all, just paths from here to there. Suppose that was controlled by any combination of micro features that were available. We could build native UC/UCC, native 5G, native content delivery networks, and all the proposed enhancements to IP without changing a single device. How’s that for future-proofing?
Nobody is talking about this now, but both the ONF and Google seem to be nibbling at the edges, and if they get there, how long will it take for other vendors, other cloud providers, to pick it up? It might be optimistic to say that the new network model is around the corner, but it’s darn sure closer than it has ever been.
