We tend to think of transformation as a proactive process, meaning that some technology shift has the effect of transforming things. It’s a nice picture for the industry, and it’s easy to understand, but the biggest transformation in networking may be happening a different way, and we may be missing it.
From its earliest days, networks have been focused on traffic aggregation for efficiency. The “access” network feeds the “metro” network, which feeds the “core” network. This structure makes a lot of sense when you assume that network traffic is created by the sum of exchanges between network users, because it ensures connectivity and a measure of network efficiency at the same time.
The problem now is that we have multiple forces that are changing what networks are really being asked to do. One force is the explosive growth in video content, growth that’s surely going to not only continue but likely accelerate as a result of greater demand for streaming video. Another is the advent of 5G, which relies more on hosted features/functions than prior generations of mobile technology, and 5G is a potential driver for our last force, edge computing. To relate these forces of change to the changes they’re forcing, we need to look at each.
Content delivery changes network dynamics because the majority of content traffic is focused on a relatively limited repertoire of material, and because the traffic levels and QoE requirements associated with video content in particular challenge effectiveness over long-haul pathways. Content delivery networks (CDNs) have for decades provided local hosting of content to enhance performance. A CDN is actually less a “network” than a hosting environment, and “local” will generally mean “within a major metro area” for best performance/economy tradeoffs.
5G, and feature hosting in general, changes the network dynamic too. In the past, “features” of networks were the result of cooperative device behavior. With mobile networks, the “devices” tended to be concentrated in the major metro areas because mobile traffic largely originates there, and the features the devices represent related to the users of the network and the management of their mobility, largely metro functions. 5G also broadens the model of feature hosting, replacing the presumption of COTS servers as the host with a wider variety of devices, some placed where singular devices would be the only economical solution. A “pool” of resources then spans both metro and access networks.
Then there’s edge computing. As a model for hosting, edge computing and 5G’s notion of a pool of resources would coincide, with edge computing embracing even the inclusion of both privately owned resources and “cloud” resources in the same pool, something that 5G operator relationships with public cloud providers also encourages. What’s interesting about edge computing is that both the CDN mission and the 5G/network-feature-hosting missions are potentially subsets of edge computing, meaning that the edge is a unifier in at least some sense.
CDNs have largely insulated the IP core from massive traffic growth associated with content delivery. 5G and edge computing seem to insulate the core from feature-related, cloud-related, future missions as well. All those things now can be expected to live primarily within the metro area, and the “metro network” then becomes much more important, to the point where it’s fair to say that the future of networking overall is the future of metro networking.
The biggest piece of that metro-network future is that the metro becomes a giant virtual data center, meaning that the primary purpose of the metro network will be to connect the pooled resources associated with the broad and unified edge mission. That means that some organized and standardized form of data center networking will be the foundation of metro networking, and that data center interconnect (DCI) will focus on creating as low a latency and as high a capacity as possible with DCI connections. There will obviously be “layers” to the virtual-data-center model, meaning that places with real server farms will be the best-connected, but other outlying locations will also be connected with sufficient capacity to ensure no significant risk of congestion and latency occur.
Operationally speaking, this demands a common model for lifecycle management, since any significant variability at the operations practices level would raise the risk of human error and delays in remediation that would, because of the growing focus on metro-hosted features and content, be a major service problem. Finally, there’s a question as to whether there needs to be a framework for building edge applications at the runtime level. Orchestration of independent components of software, particularly for event-driven applications, is a significant technology challenge, and how it’s done can reasonably be expected to impact the network requirements within the metro zone.
Competition is also certain to impact how metro networking evolves. On one hand, the metro is (as I’ve already noted) a giant virtual data center. The value of metro, and the whole reason why metro emerges as the critical opportunity point in all of networking, lies in what’s hosted rather than in how it’s connected. That would create a hosting bias to metro, and a data-center-interconnect bias to metro network planning. If we can build a data center network, could we not extend it via DCI, creating a giant fabric for metro? On the other hand, metro is also the inside of the access network, the major likely point of attack for hackers, and a place where Level 3 practices would surely scale better than Level 2. As a result, we could see a switch model of metro, a router model of metro, and perhaps some other models too.
One interesting possibility is the emergence of SDN as a unifying approach to metro. SDN is already more likely to be found in the data center than anywhere else, and SDN control of forwarding paths eliminates a lot of the issues of large L2 networks. Google, with Andromeda, has also demonstrated that SDN can be used “inside” a BGP emulator edge layer to create an IP core network, so it follows that SDN could be used to build a connectivity layer that could be purposed toward L2 or L3, or both.
Another possibility is that metro could be built out of some kind of extension to the “disaggregated” router/switch model that’s been popularized by DriveNets but is also supported by vendors like RtBrick. Obviously, a disaggregated virtual device is created by uniting multiple physical devices, and it might be possible to adapt that approach to the creation of metro-virtual devices united from multiple physical-device clusters.
The biggest change in metro, of course, is the fusion of network and hosting, which is what’s behind the “metro-as-a-giant-data-center” theme. That fusion not only changes the requirements and options for network-building, it changes the operational goals as well. It’s obvious that somebody who can’t watch video isn’t very interested in whether the CDN caching process is broken, whether the URL is redirecting wrong, or whether the network connection is bad. Edge computing, 5G feature hosting, IoT, and other stuff that will settle in the metro will have similar disregard for the exact problem source, and a big focus on optimizing the remediation. We may be creeping up on something totally new, a notion of “MetroOps”, and if we are, that notion could percolate into the cloud and the data center too.