1. SDO, Software Defined Operator
An SDO (Software Defined Operator) is an operator whose core network is fully virtualised and software-controlled. Where a traditional operator runs a hardware backbone whose behaviour it alone defines, an SDO runs the core functions (routing, switching, segmentation) in a software layer, on standard infrastructure, and can therefore delegate part of them to each customer.
sdMPLS is the technology that follows from this approach: it is the SDO concept turned into a multi-site network offer. The signature of the approach: the operator backbone, virtualised and controlled by the customer.
Virtualising the operator core is not a laboratory idea: Orange, AT&T and Verizon already have disaggregated equipment (commodity hardware and open network software) in production in their networks (Flex.eu synthesis of public data, SDO study, March 2026).
2. The VXLAN/EVPN core
Flex.eu's SDO core network is a single backbone, built on the VXLAN and EVPN standards, that carries at the same time:
- the cloud: virtual machines and hosting, delivered directly into the core;
- operator collection: the access links of all customer sites;
- the voice platform: SIP trunks and telephony services.
The architecture is spine-leaf: every access device (leaf) is connected to all the core devices (spine). Capacity is added by horizontal extension, with no central component whose capacity would cap the whole. This is what sets sdMPLS apart from a central SD-WAN orchestrator, which generally tops out at 1,000 to 2,000 sites.
VXLAN encapsulates the frames of each virtual network and seals them off from one another; EVPN distributes the control plane. Together, they let the shared core host one virtual network, and one VRB, per customer.
3. The VRB, Virtual Router Backbone
The VRB is the virtual backbone router dedicated to the customer. It runs in the SDO core, in a virtual machine of the customer's own, and is the point from which the customer controls its network. It is dedicated: it is shared with no one. sdMPLS is aimed at multi-site companies of a certain size: the VRB is single-customer, administered by the Powered by sdMPLS partner, who shares all or part of it with the end customer's team, depending on what the customer wishes to control itself.
What the VRB exposes to the customer
- Routing: tables, policies, announcements towards the sites and towards the cloud
- QoS: classes of service and flow prioritisation, with end-to-end QoS from each site's access all the way to the core and the Internet exit
- VLANs and segments: segmentation of the customer's network, in the core and not only at the edges
- Traffic engineering: choosing the paths that flows take through the backbone
The VRB exposes what a network team already knows how to do. What the customer controls is its policy; running the core (monitoring, maintenance, platform upgrades, access links) remains the operator's job.
Each VRB runs on RouterOS, MikroTik's routing system, chosen for its ergonomics and for the depth of its diagnostic tools: an interface network engineers know, a readable configuration, built-in test tools. When MikroTik routers terminate the links at the sites, which Flex.eu recommends and most customers choose, diagnostics are consistent end to end, from the site port to the core. The partner remains free to choose the termination equipment, to fit its offer to its market.
Wording to remember: sdMPLS is a VRB dedicated to one end customer. The VRB sits on the operator's SDO core network, shared and segmented by VXLAN, just as an MPLS service sits on the operator's backbone. So we say “your backbone, dedicated and under your control”.
4. Standard protocols and reversibility
sdMPLS is built on standard, documented protocols that any network team can read:
- VXLAN (RFC 7348) for the encapsulation and isolation of virtual networks in the core;
- EVPN (BGP EVPN, RFC 7432 and following) for the core's control plane;
- BGP, OSPF, VLAN, IPsec: the protocols the customer handles in its VRB, those of any router.
Consequence for the customer: the configuration of its VRB is readable text, which can be exported at any time and reused on another router. The customer is locked neither into a vendor control plane (the SD-WAN case), nor into hardware and long contracts (the operator MPLS case), nor into a closed core that can only be changed by ticket (the MPLS-over-collection case).
5. Performance and software stack
More than 3 million packets per second per VM: real backbone performance, not that of a software overlay. Public benchmark in preparation.
Why packets per second matter
A virtualised router does not saturate first in gigabits per second, but in packets per second (pps). Real business traffic is made of small packets: voice, web requests, acknowledgements, TLS handshakes. Every packet costs the processor the same work whatever its size. This is what long limited virtualised routing on standard servers: bandwidth remained available, but the VM's processor saturated, with throughput drops and latency as a result. This is the bottleneck the sdMPLS platform was designed to remove.
What makes the difference: the network layer rewritten by Flex.eu
The SDO core runs on Proxmox, whose network layer Flex.eu has rewritten: the leaf switching functions are integrated into the hypervisor and accelerated by Nvidia network cards, in direct communication with the spines, with no intermediate access equipment. Each VRB runs in its own VM and benefits from this data path: this is where performance is won, and this layer, specific to Flex.eu and the result of more than five years of research and development, is the heart of sdMPLS.
The software stack therefore has three parts: Proxmox, a European hypervisor, for execution and the geo-cluster; the accelerated network layer developed by Flex.eu; RouterOS for each customer's VRB. A stack that is frugal in licences, which shows in the price, and a platform that Flex.eu develops, hosts and operates itself.
As a matter of prudence, Flex.eu publishes no quantified comparison with other software routers until the public, reproducible benchmark is available. The method (packet size, test conditions) will be published with the results.
6. Access links and collected networks
Sites connect to the SDO core over standard access links, at market prices, chosen site by site according to eligibility and criticality:
FTTH
Shared fibre, for branches and small sites.
FTTO
Dedicated business fibre with guaranteed bandwidth, for head offices and critical sites.
xDSL
ADSL or SDSL, where fibre is not yet available.
4G / 5G
Backup, temporary sites, provisional start-up before the fixed link is delivered.
Mobile access relies on Flex.eu's MVNO offer on the Bouygues Telecom network; integration of the Orange network is planned for mid-2027. The link is an access to the core: changing a link's technology (xDSL to fibre, for example) does not change the customer's configuration in its VRB.
Eleven infrastructure networks collected
Fixed accesses are collected directly into the SDO core from the networks of Orange, SFR, Bouygues Telecom, Covage, Axione, IELO, Nexloop, Eurofiber, XP Fibre, Colt and Free, as FTTH, FTTE, FTTO and SDSL. For each site, the partner chooses the network and the type of link according to eligibility, criticality and budget; the customer's VRB only sees one more access. This diversity covers the whole country, including areas served by a single operator, and avoids depending on one infrastructure network. The collection gateways to these networks are secured by a dual gateway for most delivery modes, and this duplication is being generalised.
Collected directly into the core, off the public Internet
These links are not Internet links. They are delivered into the sdMPLS core network through direct private collection gateways between operators, with private APNs for mobile: traffic between the customer's sites never transits the public Internet or third-party operators. Internet access goes through a single Internet exit at the core network, via Flex.eu's BGP routers and transit, according to several technical models of shared exit behind a firewall — including for the 4G/5G SIM cards issued to employees, which join the company network with the same security policy as the sites. Just like MPLS, then: a private network with a single, controlled Internet exit.
Consequence: since the path is controlled from each site's access all the way to the core and the Internet exit, end-to-end QoS can be defended. What remains variable is the level of commitment specific to each type of link (FTTO with guaranteed bandwidth, shared FTTH), chosen by the customer site by site.
7. Security, segmentation and hosting
The SDO core is shared between customers; its segmentation relies on VXLAN/EVPN, which creates sealed virtual networks, and on the principle of one VRB per customer: no routing instance is shared. The customer can itself segment its own network inside its VRB.
The customer's network is off the public Internet: traffic between its sites never transits the public Internet, and Internet access goes through a single exit at the core, behind a firewall, with the same security policy for the sites and for the employees' 4G/5G SIM cards (see Access links).
Hosted in France, as a geo-cluster
The SDO core and the VRB configurations are hosted in France, in two separate Digital Realty data centres in the Paris region. The core is deployed there as a Proxmox geo-cluster: two core networks on each site, i.e. four cores, so as to remain redundant and available whatever the failure, of a device or of a whole site. 99.95% availability and a 4-hour guaranteed time to repair (GTR), 24/7, included. These commitments cover the core network; at the access, the type of link chosen site by site (dedicated fibre with guaranteed bandwidth or shared fibre) sets the level of commitment.
A French solution, controlled end to end
sdMPLS is designed, developed, hosted and operated in France by Flex.eu. Its software building blocks are European (Proxmox, RouterOS); the network layer behind its performance is developed by Flex.eu; no control plane sits with a hyperscaler or a foreign SD-WAN vendor; routing and monitoring data never leave Flex.eu's cores. Operation of the platform and its updates are handled by Flex.eu. For a company or a public body that cares about where its network lives and who controls it, this is a concrete answer, verifiable on documents.
8. Points to watch
An honest comparison also says what to look at closely. Two points, and how sdMPLS answers them.
- A single operator for collection and core. That is the principle of any operated private network, MPLS included. What matters is that operator's robustness (four cores in a geo-cluster across two data centres, eleven infrastructure networks collected) and your freedom to leave: the VRB configuration exports as plain text, over standard protocols.
- The mobile backup must stay inside the private network. A consumer 4G/5G SIM exits onto the public Internet and does not enter a network that is off the Internet without a tunnel and an appliance to secure at the site. sdMPLS uses SIMs on a private APN, collected into the core, with the same security policy and the same QoS as fixed links: a requirement to write into any tender.
9. Market benchmarks
Context figures: Flex.eu synthesis of public market data (analysts, operators), SDO study, March 2026. These are sourced benchmarks, to be distinguished from Flex.eu's own estimates.
Source: Flex.eu synthesis of public market data (analysts, operators), SDO study, March 2026. Market: global MPLS $27.7bn (2025), SD-WAN $9.3bn; French MPLS IP VPN market $1.88bn (2023).
The SDO core in figures
Source: Flex.eu, September 2026.
Lead times. Delivery of an access link depends on the infrastructure operator serving the site: from a few days to a few months depending on the case. A site whose link already exists is connected in a few days. And every change to the network (routing, QoS, segmentation, opening a flow) takes effect instantly from the VRB: that is where the difference lies with the 60 to 120 days of MPLS, where every change goes back through the operator.