The biggest question for service provider networking in 2023 may never have been asked. That question is “What role will metro play, and what architecture will support that role?” The answer will not only determine what happens to the revenues of network operators, but also how each network equipment vendor will fare, and whether upstart players like DriveNets will really change the market for routers. It will also determine just how important non-router elements are to the network.
A service provider network is, broadly speaking, a hierarchy that’s made up of access edge elements and a series of concentration elements that end up creating the “core” network. In the core, the emphasis is on economies of transport; you need big iron that can push a lot of packets very fast and very cheaply. At the edge, the specific model will depend on just what kind of service the service provider is offering. An operator who offers only business broadband would look very different from one that’s supporting mobile networks, and those offering consumer wireline broadband would look even more different. At the edge, whatever the model is, there’s still a need to push packets economically, but since customers connect there, any personalization in customer care and service features are easiest to inject there.
Easiest perhaps, but not necessarily most economical. The problem with the access edge is that there are too many places and too few customers per access site to ensure economy of scale, particularly with hosted elements of a service. Edge computing is most economical if you can pull the hosting points inward a bit; not so far that you have too much traffic to analyze but far enough that you can justify reasonable hosting economies. The sweet spot is the “metro”.
Metro networking traditionally means the point where access elements are connected for aggregation. It also means the network piece that resides in the commercial center of a given market geography, and that combination is ideal if you want to add value by supporting real-world activities like going to work, shopping and eating out, and so forth. Collaboration and connection is most easily supported by technology that can be used by all the likely partners, and we tend to relate more with the people and places we can touch.
Metro is where we jump from features to transport, access to core, a lot of little boxes to a few big boxes, a pure connectivity mission to a feature-and-service mission. Real customer management focuses there too. Best of all, there are still a lot of metro boxes. Globally, there are thousands of metro locations, perhaps even tens of thousands, and my model has consistently said that if we were to carry edge-enabling applications far enough, we could generate a hundred thousand new hosting points, each in a metro location. Metro is thus the place where router meets switch, where connectivity meets applications, and where data centers meet networks.
And that point, that last point, is critical. There are three possible relationships between data centers and networks, and each drives metro differently, creating different requirements and opportunities…and different winners and losers.
The first possibility is that no real features are injected at the metro point at all, so any hosting there is confined to what we could call “virtual function” support. This would have a minimal impact on both services and on metro requirements, and thus would mean that metro would retain its current focus on traffic aggregation and being an on-ramp to the core. This scenario would mean little change could be expected in either metro requirements or vendor incumbencies.
The second possibility is that there are feature connections made in the metro, but the features are hosted in the public cloud, likely via relationships established between operators and cloud providers. If this is the case, then it’s likely that these features would be delivered either via a single (redundant) trunk link or integrated with the service above or outside the network, in the user’s device or via a high-level service API that the cloud provider hosts. This would increase the management complexity, but not radically change the equipment requirements.
The final possibility is that there would be functional integration between hosted features and router features injected at the metro level. This could come about either because operators directly invested in “carrier cloud” or partnered with cloud providers in a way that required tight coupling, likely because operators provided facilities and local connectivity to cloud partners. In this case, metro is the focus of future service value add overall.
I believe that AT&T’s approach to “facilitating services” is the right answer for operators. I believe that approach will require tight coupling between hosting and network, and I also believe that operators will inevitably build out carrier cloud on their own, at least in the areas where they have a major customer footprint. I don’t think that the first ships-in-the-night model will serve operator needs to boost revenue per bit, and I think the second strategy of a kiss-through-cellophane interface is only a transitional approach.
Presuming I’m right (which, of course, I’d presume), then the architecture of metro has to change radically, creating what’s much more like a large data center network with a bigger-than-usual transit routing element that bridges between access, core, and data center networks. Given the sheer number of metro areas to network, this radical change could end up impacting most operator spending on network equipment.
Which raises the question of just what the new architecture would look like. Obviously it has to be something that’s more fabric-centric, because the assembly of features into services can’t be allowed to generate a lot of latency. Obviously that means that it’s going to be very switch-like. However, it’s also still an aggregation element, and so it has to have that capability as well. Finally, it’s likely that proximate metro centers would network with each other directly rather than through the core, because these clusters of metro create what’s actually an economic unit, and economic units are the foundation of application opportunities, particularly ones based on a broader (and more sensible) conception of the metaverse.
Both major vendors (Cisco and Juniper) and startups (DriveNets) could build this sort of thing with their current product sets. It’s therefore going to be a question of positioning the assets properly, and that could be done very, very, quickly. DriveNets and Juniper have taken steps already, and operators tell me that Cisco has been talking about metro at the sales level for about six months, though their marketing/positioning is still lagging a bit. Broadcom, with its position in the white-box and fabric space and bolstered by VMware’s hosting, virtualization, and virtual networking, might also take a run at things.
If broader economic issues that derailed 2022 pass, as I think they will, then 2023 may be the year when this new vision solidifies.
