--- title: Network disaggregation in telecommunication transport networks description: Telecommunications networks have traditionally been built from tightly integrated systems. A router vendor supplies the forwarding hardware, network operating system (NOS), routing protocols, management interfaces, upgrade process, and support contract as one product. However, growing demands for flexibility and cost control have prompted […] url: https://canonical.com/blog/network-disaggregation?format=md --- 1. [Blog](https://canonical.com/blog) 2. Article --- [Benjamin Ryzman](https://canonical.com/blog/author/benjaminryzman "More about Benjamin Ryzman") 16 September 2026 # Network disaggregation in telecommunication transport networks [networking](https://canonical.com/blog/tag/networking) --- Share the article Telecommunications networks have traditionally been built from tightly integrated systems. A router vendor supplies the forwarding hardware, network operating system (NOS), routing protocols, management interfaces, upgrade process, and support contract as one product. However, growing demands for flexibility and cost control have prompted a new model: the disaggregated network. Network disaggregation is the practice of separating the hardware and software components of a network device so that they can be selected, purchased, and managed independently. Instead of relying on one supplier for the complete router, an operator can combine hardware, network software, and operational tooling from different vendors within a validated and supported platform. The disaggregated model promises greater supplier choice, more control over technology lifecycles, and a more programmable network. It also changes who is responsible for integration, testing, security maintenance, fault resolution, and long-term support. This article examines both sides of that trade-off. It explains how disaggregated transport platforms are assembled, why telcos have historically approached them with caution, and how regulatory and supply-chain requirements affect the available choices. It also reviews the main NOSs used in open networking and considers what can be learned from production deployments at operators like AT&T and Comcast. While network disaggregation is already a practical option for telco transport networks, hardware and software choice alone do not make it successful. Operators need a repeatable reference architecture, clear accountability across suppliers, and a maintained operating system (OS) foundation. Where network software vendors and hardware manufacturers choose to collaborate, Ubuntu Long Term Supported (LTS) releases can provide that common foundation for hardware enablement, lifecycle management, and long-term maintenance. ## What a disaggregated transport platform looks like Network disaggregation is a spectrum, rather than a single architecture. In its simplest form, an operator buys a fixed-format router or switch and runs a NOS from another supplier. The hardware and software may still arrive as a validated combination, supported by the NOS vendor, the Original Equipment Manufacturer (OEM), or the systems integrator. More extensive designs separate additional layers. A transport platform may combine merchant forwarding silicon, hardware from an original design manufacturer, a board support package, a Linux base OS, an independent NOS, and separate automation and assurance systems. Some vendors also distribute one logical router across several forwarding devices. This replaces a proprietary chassis with a group of standardized systems managed as one routing platform. Software routing on general-purpose servers provides another option. It can be appropriate for service-heavy edge functions or workloads that fit the capabilities of CPUs, NICs, or accelerators. Specialized switching silicon remains important where the network requires high port density, large forwarding tables, deep buffers, deterministic performance, timing, or advanced quality-of-service behavior. The useful question is therefore not whether to disaggregate everything or to leave it as is. Operators must decide which layers to separate, which combinations to standardize, and who will support the resulting system. ## Why operators consider network disaggregation The first benefit of network disaggregation is greater supplier choice. Separating the NOS from the hardware can let an operator qualify several platforms for the same software environment or retain the same hardware while changing the network software. This can reduce dependence on one equipment supplier and provide alternatives when products reach end of life, vendors change strategy, or national procurement rules restrict certain suppliers. Network disaggregation can also make costs more transparent. Hardware, software, support, optics, and integration can be evaluated separately, rather than purchased as one bundled platform. That transparency can improve commercial leverage, particularly at scale. Lower equipment prices do not guarantee a lower total cost, however. The operator must also fund qualification, automation, lifecycle testing, staff development, spares, and multi-vendor support. The strongest business case for network disaggregation usually appears where a small number of standardized designs can be deployed across a large fleet. Independent hardware and software lifecycles provide another advantage. Operators may refresh forwarding capacity without replacing the routing environment, or introduce new routing and telemetry capabilities without changing otherwise serviceable hardware. This flexibility depends on disciplined compatibility management. Firmware, drivers, the silicon Software Development Kit (SDK), the base OS, the NOS, and the management layer must be validated as a complete versioned stack. Modern disaggregated platforms also tend to expose model-driven configuration and streaming telemetry through interfaces such as [NETCONF](https://datatracker.ietf.org/doc/html/rfc6241), [OpenConfig](https://www.openconfig.net/), and [gNMI](https://www.openconfig.net/docs/gnmi/gnmi-specification/). These interfaces support a more software-driven operating model, where configuration, validation, and remediation can be automated. However, the presence of an API alone is insufficient for production-grade network automation. Operators still need stable models, predictable behavior, useful errors, complete telemetry, and compatibility across upgrades. ## Why telcos have moved cautiously Telco caution reflects operational reality, rather than resistance to change. Transport networks carry long-lived services under demanding availability targets. Their processes, inventories, assurance systems, and staff expertise have often developed around a small set of integrated vendors. These integrated vendors validate the Application-Specific Integrated Circuit (ASIC), firmware, OS, routing stack, optics, management interfaces, and upgrade process as one product. In a disaggregated design, this responsibility must be reassigned. Someone must define the supported combinations, run regression tests, reproduce faults, coordinate engineering teams, and decide when a release is ready for production. The operator can take that role, assign it to a lead vendor, or rely on a systems integrator. Leaving it undefined creates a support gap. Network and hardware compatibility also extends far beyond establishing a routing session. A transport platform must be tested for route and label scale, convergence, quality of service, buffering, multicast, timing, optics, telemetry, failure behavior, and upgrades. Because of this breadth of requirements, compatibility cannot be inferred from a single integration point or a basic routing test. A generic claim that a NOS supports a silicon family does not prove that every device based on that silicon will behave identically. Platform memory, port design, firmware, sensors, optics, and exposed ASIC capabilities can all differ. When these differences are not fully validated, operators risk inconsistent behavior across devices, unexpected failures under load or scale, degraded quality of service, and difficult-to-diagnose performance issues. It can also lead to upgrade failures that disrupt live traffic, increased operational overhead for troubleshooting and testing, and ultimately service instability that impacts Service Level Agreements (SLAs) and user experience. Fault isolation becomes more difficult as well. A forwarding failure may originate in the routing process, silicon SDK, hardware abstraction layer, kernel driver, platform firmware, optics, or automation system. Without a single clear escalation path across those boundaries, issues are often bounced between teams, slowing diagnosis and extending outages. Operators need one clear escalation path across those boundaries. Skills can become a further constraint. Network disaggregation favors organizations with strong Linux, routing, software lifecycle, automation, and validation capabilities. Operators without those resources can still adopt a disaggregated architecture, but they will usually need a vendor or integrator to provide a supported reference architecture. However, these factors do not mean that network disaggregation is generally avoided. Rather, the approach of many telcos is to begin with bounded domains such as access, cell-site routing, aggregation, peering, or the replacement of high-volume platforms approaching end of life. ## Production deployments show that the model works AT&T has developed one of the most visible disaggregated routing programs. In 2023, the operator [reported](https://about.att.com/blogs/2023/satterlee-open-disaggregated-platforms.html) that more than half of its production traffic had moved to next-generation core routers based on Broadcom silicon, a distributed disaggregated chassis architecture, and DriveNets software. AT&T has also deployed disaggregated platforms at the edge and in cell-site routing. The important lesson from AT&T’s architecture is not simply that white-box routers can forward production traffic. AT&T created specifications, qualification processes, automation, and supplier relationships around the complete platform for it to function efficiently. Comcast Corporation has followed a related path with its [Janus architecture](https://corporate.comcast.com/press/releases/comcast-harnessing-cloud-and-ai-to-transform-next-generation-internet-experiences). The company describes Janus as replacing proprietary routing and transport appliances with white-box hardware and independently developed software. Telemetry, analytics, and automated remediation are central to Janus’ design. This reinforces a broader point: standardized hardware creates the foundation, while software operations determine whether network disaggregation can succeed at scale. These examples show that the integration challenge can be overcome. They do not imply that every operator should reproduce the same model. Most will adopt a narrower set of validated combinations, often with stronger support from vendors and systems integrators. ## Regulation changes the requirements, not the architecture Regulation rarely requires an integrated or disaggregated router. It defines the security, resilience, and supply-chain controls an operator must maintain, regardless of the architecture chosen. In the United Kingdom (UK), the [Telecommunications Security Act](https://www.legislation.gov.uk/ukpga/2021/31/contents) framework requires public telecom providers to manage security risks across their networks and suppliers. The associated regulations and [code of practice](https://www.gov.uk/government/publications/revised-telecommunications-security-code-of-practice-2026-version-11) place detailed expectations on access control, change management, monitoring, vulnerability handling, and lifecycle governance. The [European Union’s NIS 2 Directive](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng) similarly requires electronic communications providers to manage cybersecurity and supply-chain risk. Likewise, the [Cyber Resilience Act](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng) adds lifecycle security obligations for products with digital elements, including vulnerability handling, updates, documentation, and defined support periods. Other jurisdictions use different mechanisms. The United States, [as detailed by the Federal Communications Commission](https://www.fcc.gov/supplychain/coveredlist), maintains restrictions on equipment and services considered an unacceptable national security risk. India requires designated telecom equipment to be sourced from “trusted sources”and listed on the Government of India’s [Trusted Telecom Portal](https://trustedtelecom.gov.in/) under the National Security Directive on the Telecommunication Sector (NSDTS). In Australia, the [Security of Critical Infrastructure Act 2018](https://www.legislation.gov.au/C2018A00029/latest/text) (SOCI), strengthened by the [Telecommunications security reforms](https://www.homeaffairs.gov.au/nat-security/Pages/telecommunications-sector-security.aspx), brings critical telecommunications assets within the broader critical-infrastructure security framework. The reforms consolidated earlier telecommunications sector security obligations into the SOCI regime, covering areas such as risk management, incident response, and security of critical telecom infrastructure. These frameworks can encourage supplier diversity, but they can also restrict which hardware, firmware, and software combinations are acceptable in practice. A disaggregated platform may provide greater transparency into its components and their provenance. It also creates more supplier relationships that operators must govern. Operators need clear evidence about who maintains each layer, how vulnerabilities are reported and fixed, how privileged access is controlled, and how long each component will be supported. ## Which NOS to choose? The landscape Different NOS products have distinct architectural origins and target use cases. They should not be treated as equivalent software packages. Some options are explained below. SONiC is an open source NOS with a containerized architecture and a hardware abstraction layer based on the Switch Abstraction Interface (SAI). Its strongest adoption remains in cloud and data center switching, although routing capabilities and telecom deployments continue to grow. Learn more about SONiC [on our blog](https://canonical.com/blog/sonic-the-open-source-network-operating-system-for-modern-data-centers). [Community SONiC](https://sonicfoundation.dev/) provides a common upstream project and broad ecosystem for SONiC. It is best suited for evaluation, development, and highly engineering-led environments where operators have the capability to integrate, validate, and operate the platform without relying on vendor-managed support. Most operators will still need a commercial distribution, OEM, or systems integrator to qualify a specific platform, maintain it, and provide accountable support. [IP Infusion OcNOS](https://www.ipinfusion.com/products/ocnos/) is a commercial NOS designed for open networking hardware. Its service-provider editions are specifically targeted at carrier-grade network deployments, including access and edge aggregation layers, metro and core Multi-Protocol Label Switching (MPLS) backbones, and modern transport architectures such as segment routing over MPLS (SR-MPLS) or over IPv6 (SRv6), Ethernet Virtual Private Network (EVPN) based Ethernet services, and timing-sensitive networks used for mobile backhaul and 5G transport. It is also commonly positioned for IP-over-optical integration use cases, where IP routing and optical transport layers are tightly coordinated in disaggregated environments. [Arrcus ArcOS](https://arrcus.com/products/arcos) is a modular NOS for physical, virtual, and distributed routing. It targets data center, peering, connected-edge, and transport environments, with an emphasis on programmatic operations on merchant-silicon platforms. [DriveNets Network Cloud](https://drivenets.com/products/) uses a distributed architecture, in which several forwarding devices operate as one logical router. It targets core and high-scale edge roles traditionally served by proprietary chassis systems. [RtBrick FullStack](https://www.rtbrick.com/our-routing-software) focuses on multiservice edge and provider-edge routing, including broadband network gateway, peering, and service-provider applications. Its disaggregated, software-defined architecture separates control and forwarding functions, enabling it to scale and adapt efficiently at the network edge, which is why it is well-suited to high-throughput, multi-tenant use cases such as broadband aggregation, interconnection, and service-provider edge routing. The practical choice of NOS for each organization depends on the role of the device, supported protocols, scale, hardware compatibility, operating model, and lifecycle commitments. A platform suitable for a data center leaf may not meet the requirements of an MPLS aggregation router or broadband edge, so it is critical to define the target use case and parameters clearly before deciding on a platform. ## Why the base OS matters Network disaggregation exposes a layer that integrated appliances often hide: the underlying OS. The base OS provides the kernel, drivers, boot process, user management, logging, package lifecycle, and system services. It also hosts routing processes, management agents, and hardware abstraction components. Some NOS vendors package this foundation as an inseparable part of their image. Others can work with hardware manufacturers and an OS publisher around a common Linux base. A consistent base OS can reduce duplication in the ecosystem, and this reduction is what enables several downstream benefits. NOS vendors can target a common software environment across multiple platforms instead of maintaining fragmented, platform specific builds. Hardware vendors can align and streamline their board support packages against a known OS baseline, reducing parallel engineering effort. As a result, operators, in turn, benefit from a more consistent lifecycle and management model. Replacing the Linux distribution under an existing NOS is rarely a simple packaging exercise; rather, it becomes a longer-term engineering collaboration. To succeed effectively, the NOS vendor, hardware OEM or Original Device Manufacturer (ODM), silicon provider, and base OS publisher must work together. ## Ubuntu LTS as a foundation for network software Ubuntu LTS can provide a common OS layer where NOS vendors and hardware manufacturers choose to integrate around it, making it a strong choice for disaggregated networking. Its predictable [release cycle](https://ubuntu.com/about/release-cycle) and long security maintenance commitment suit transport platforms that remain in service for many years. Ubuntu Pro, Canonical’s optional enterprise-grade subscription, extends security maintenance and package coverage to the Ubuntu base operating system and a broad set of packages, including components that may not be covered by standard Ubuntu security updates. It can provide extended security maintenance for supported Ubuntu LTS releases, access to security fixes for high and critical severity vulnerabilities, kernel live patching for eligible systems, and additional compliance and support features. This gives transport operators and technology partners a clearer basis for lifecycle planning, vulnerability management, fleet-wide patching, and maintaining systems throughout extended deployment support period. Learn more about what packages are covered under [Ubuntu Pro on our website](https://ubuntu.com/pro). Ubuntu Pro can also [support the technical controls required by frameworks such as NIS 2](https://ubuntu.com/security/nis2) and the UK Telecommunications Security Code of Practice. Canonical provides [Expanded Security Maintenance](https://ubuntu.com/security/esm) (ESM) for eligible Ubuntu LTS packages beyond the standard support period, while the [Ubuntu Security Guide](https://documentation.ubuntu.com/security/docs/compliance/usg/) supports automated hardening and auditing against recognized baselines. Finally, [Landscape](https://ubuntu.com/landscape) adds fleet inventory, patch status, policy enforcement, and audit reporting. It is important to note that while these capabilities make the route to compliance simpler for operators, they do not make a complete network platform compliant on their own. Additional measures may still be required, including appropriate governance, risk-management processes, access controls, monitoring, incident response, supply-chain assurance, documentation, and evidence that security policies and regulatory obligations are being met. Ubuntu Pro’s capabilities can reduce the base OS work needed to manage vulnerabilities, but compliance ultimately depends on the security of the broader platform, its operational environment, and the processes used to manage it. Canonical supports operators throughout the hardware lifecycle, from initial enablement to easing management and maintenance. To ensure that the hardware choice functions effectively with Ubuntu, Canonical can work with silicon providers, OEMs, and NOS vendors on drivers, firmware, board support packages, and platform validation. Once the system is ready to deploy, [MAAS](https://canonical.com/maas) can support repeatable provisioning where the appliance design permits it, providing API-driven discovery and commissioning for physical infrastructure. This helps operators validate and deploy disaggregated hardware more consistently, reducing integration effort and making it easier to scale and maintain the resulting infrastructure. In essence, Canonical can provide the maintained Linux foundation, hardware enablement, and lifecycle tooling around which partners such as NOS vendors, product manufacturers and system integrators can build and support a validated network platform. ## In conclusion: Network disaggregation changes who owns the system Ultimately, integrated routing platforms will remain appropriate where mature feature coverage, one supplier, and a unified support path matter more than component choice. However, network disaggregation becomes compelling where operators can turn supplier diversity into a repeatable engineering system. Hardware, the NOS, the base OS, automation, validation, and support must be designed together. AT&T and Comcast show that this can be achieved in large production networks. Their deployments also show why white-box hardware alone is not the outcome. Software lifecycle, observability, automation, and operational accountability make the architecture viable. Ubuntu LTS can provide a consistent and maintained foundation for this ecosystem. Realizing that value requires collaboration with the ISVs and OEMs that deliver the complete platform. Canonical’s role is therefore to help networking software and hardware partners build disaggregated systems that operators can provision, maintain, validate, and support over the long lifecycle expected from telco transport infrastructure. [Talk to Canonical’s networking team](https://canonical.com/networking-contact-us) about building and validating a disaggregated networking platform on Ubuntu LTS. [Get in touch Interested in running Ubuntu in your organization?](https://ubuntu.com/about/contact-us/form) ## Sign up for our newsletter Get the latest Canonical news and updates in your inbox. Work email: \*I agree to receive information about Canonical's products and services. By submitting this form, I confirm that I have read and agree to [Canonical's Privacy Policy](https://canonical.com/legal/dataprivacy). Sign up ## Share on --- ## Related posts [### What is InfiniBand?](https://canonical.com/blog/what-is-infiniband) When distributed workloads stall because nodes cannot exchange small messages quickly and consistently, the network is the limiting factor. How do you solve that problem?... [Benjamin Ryzman](https://canonical.com/blog/author/benjaminryzman) 2 June 2026 [### What is RDMA?](https://canonical.com/blog/what-is-rdma) Modern data centres are hitting a wall that faster CPUs alone cannot fix. As workloads scale out and latency budgets shrink, the impact of moving data between servers is... [Benjamin Ryzman](https://canonical.com/blog/author/benjaminryzman) 11 February 2026 [### Canonical and NVIDIA BlueField-4: a foundation for zero-trust high performance infrastructure](https://canonical.com/blog/canonical-and-nvidia-bluefield-4-a-foundation-for-zero-trust-high-performance-infrastructure) At NVIDIA GTC Washington D.C., Canonical is pleased to support the arrival of the NVIDIA BlueField-4 – the newest generation of the data processing unit (DPU) family. NVIDIA... [Benjamin Ryzman](https://canonical.com/blog/author/benjaminryzman) 28 October 2025 [### Canonical Kubernetes meets NVIDIA DOCA Platform Framework (DPF): building the future of DPU-driven infrastructure](https://canonical.com/blog/canonical-kubernetes-meets-nvidia-doca-platform-framework-dpf-building-the-future-of-dpu-driven-infrastructure) The combined solutions simplify infrastructure operations and accelerate time-to-value for AI, telecom, and enterprise computing workloads. Accelerate deployment and operations... [Benjamin Ryzman](https://canonical.com/blog/author/benjaminryzman) 11 June 2025