System approach Edge routers have been an essential part of the Internet for decades, connecting access networks – corporate LANs, mobile and broadband networks – to the global backbone.
These devices often have cryptic names – MPLS VPN Provider Edge routers, S/P-Gateways in the case of mobile networks and Broadband Network Gateways (BNG) in the case of fiber networks – but essentially they are IP (L3 ) packet forwarders, sometimes complemented by features to support the business logic required by commercial access providers. But the world is changing and the shape and function of the edge router is changing with it.
To account for modern cloud technology, especially the rush to the edge, we expect it to be less common to think in terms of edge networks connecting to backbone networks. Instead, we will think in terms of local edge clouds connecting to global hyperscalers. Devices demand service from an edge cloud, which sometimes forwards requests to external clouds (see, for example, Cloudflare Workers and Fly.io), leaving the trend of true end-to-end connections the exception.
The edge router will increasingly be realized as a disaggregated collection of virtual functions rather than through a physical box
L3 connectivity is still there, of course, but it will increasingly be an implementation detail. And when this transition takes place, the L3 data plane will be housed in the edge cloud’s switching structure, with the corresponding control plane (whether IETF specified, 3GPP specified, BBF specified, or proprietary) implemented by microservices running in the cloud (on the edge or centralized).
That is, the edge router will increasingly be realized as a disaggregated collection of virtual functions rather than through a physical box, with control in the cloud and with the data plane running on specialized infrastructure for speed and scale. In this sense, we see the paradigm introduced by SDN – logically centralized control with distributed forwarding – making its way to the edge.
SD-WANs are a current example of applying an SDN architecture to the edge, and more recently, cloud-provided Secure Access Service Edge (SASE) services combine layers of security into the solution. But the pattern is much the same – L3 packet forwarding in the data plane coupled with a rich cloud-based control plane – with significant (functional) overlap with cloud-native implementations of access gateways.
And since most of today’s SD-WAN offerings are vertically integrated and proprietary, we could argue that the benefits of SDN (such as the ability for network operators to customize functionality) are only partially delivered in these solutions today. .
Once you stop thinking in terms of “edge routers as dedicated devices” and start seeing “routing as yet another edge feature”, it’s a small step to realize that today’s diverse array of edge routers are all fundamentally different. is the same, and that it is possible to build a generalized (and disaggregated) edge routing capability that accommodates them all. This feature can be centrally orchestrated and deployed, with functional elements running across multiple edges where case-specific package processing needs to take place.
Easier said than done of course, but it seems a likely outcome, and worth a little forethought. The key insight is that all the scenarios outlined above have a similar structure, with L3 forwarding in the data plane complemented by support for:
Safe tunnels → requiring encapsulation/decapsulation
Differentiated service → requires Q-in-Q tagging and class-based queues
Billing and accounting → counters needed per flow
Policy Enforcement → Require Access Control Rules
Observability → requires in-band network telemetry
And a microservices-based control plane that implements:
Authentication → enable changes in dataplane tunnels
Subscriber management → trigger updates for counters and queues by flow
Mobility and Routing → Trigger forwarding changes based on resource availability
Session and policy management → changes trigger access control rules
Diagnostics and anomaly detection → triggering changes in in-band network telemetry
All the functions of the data plane can be realized in P4 programming forwarding pipelines (more on that later), where the “triggering” relationship in the list of control functions helps us understand how to create a converged control/data plane interface — something called P4-Runtime ( P4RT) supports.
An example of the generalized data plane already exists and we describe it in our SDN book. It is the fabric.p4 program that implements the forwarding pipeline for ONF’s SD-Fabric, which (a) implements L3 forwarding for the leaf-spine switching fabric you would find in an edge cloud, and (b) can be extended to connect different entrances. network technologies (5Gs UPF and a PON-based BNG) to the Internet.
The current implementation is a bit crude (it uses
#ifdef), but the idea is clear: it is possible to build an L3 forwarding pipeline that can be extended with access-specific “plugins”.
As you pop up a level, imagine iterating on fabric.p4 until you have an extensible edge cloud data plane suitable for all the use cases described above. The P4RT-generated interface could then support multiple control plane tenants, for example, allowing a 3GPP-defined core and an SD-WAN controller to independently set queue parameters, define encapsulation/decapsulation labels, install forwarding rules, and so on.
Edge computing has a bright future, even if no one knows exactly what that looks like
Convergence on a shared data plane, but accepting that multiple control planes will coexist is a good starting point. But convergence at the control plane is also likely within reach, where we can expect a converged data plane to catalyze that process.
In my view, it is mainly a matter of coordinating incentives for the various domains. Already, the BBF is working on a converged access network control plane that aligns with the 3GPP-defined mobile core, largely because telcos have an incentive to make that happen.
Another good example is Magma, which defines a unified control plane and programmable data plane for both RAN-based and Wi-Fi-based wireless networks. As enterprises begin to roll out private 5G, the pressure to unify how they are managed will only increase.
The SD-WAN use case is more of a wildcard. On the one hand, SD-WAN is surprisingly similar to SD-RAN in the functionality it needs from an edge router. On the other hand, SD-WAN offerings have so far resisted disaggregation. The same was, of course, true for telco access networks until recently.
Operators will be given the option to customize the functionality instead of just accepting the bundle that comes from the router vendor
If we accept that unification of edge routing is possible, a reasonable next question is: is it desirable? I’d say the value will come from disaggregation first, as we’ve already seen in other environments like the cloud data center.
Once the control plane is separated from the data plane, innovation in both can take place more easily and the operators of these devices are given the ability to customize the functionality instead of just accepting the bundle that comes from the router vendor.
And second, there is an opportunity to take a more holistic view of the edge, offering the opportunity to apply consistent network policies that are independent of access technology. But this is a topic for another post. ®