Why Disaggregated Networks Need Orchestration

Tom Nolle blog DNOR

The two hottest marketing terms in the network equipment space are surely “disaggregated” and “cloud”, but talk is cheap, as they say.  The truth is that while almost every vendor uses those terms, only one really delivers on the combination, and that vendor is DriveNets.  What separates DriveNets from the rest, what delivers on those hot marketing claims, is the concept of orchestration.

“Disaggregated” networks can mean many different things.  Router vendors say they’re disaggregating when they sell their software and hardware separately, which lets them turn the software into a recurring subscription revenue stream.  Not much of a user benefit, right?  The better kind of “disaggregation” is using clusters of off-the-shelf white-box switches to create a whole family of “routers”, from edge to core, which is what DriveNets Network Cloud does.

To Learn More, Download the White Paper:

DNOR – DriveNets Network Orchestrator


The first step in this kind of disaggregation is to avoid having all those white boxes look like individual monolithic routers, and the process of collecting them into your various router “models” be something that doesn’t require a lot of special skills and introduce a lot of operations overhead.  Our disaggregated collection of white-box switches should be a kind of cluster resource pool, like the resource pool of cloud computing.

But what makes a cloud resource pool, which is really just a whole series of connected servers, into a unified virtual host?  The specific thing that makes cloud-computing-like disaggregated networks possible is orchestration.  In cloud computing, orchestration is the task of assigning containerized software microfeatures to hardware hosts, and that’s what’s needed just to get a “disaggregated router” organized. 

Orchestration with DriveNets

In DriveNets’ “Network Cloud architecture” , orchestration is handled by the DriveNets Network Orchestrator, DNOR, and DriveNets just released the 2.0 version of DNOR to take orchestration, literally, to the next level.  From the first, DriveNets’ Network Cloud let network operators compose a specific router from white-box hardware and microfeature software.  That was the first step, and DNOR 2.0 is now taking the second step.


Without DNOR orchestration, a disaggregated “cluster” router is a series of white-box switches and software components, all connected by a fabric.  Every hardware and software element has to be managed separately, and every hardware/software router instance looks like a separate router to other routers and to the management system.  Since we all know that the complexity of the system is proportional to the number of relationships within it, this just doesn’t scale operationally.  You could lose more in opex costs than you’d gain in capex savings. 

With DNOR orchestration, a DriveNets Network Cloud, a disaggregated cluster, is made to look like a single router in all respects.  Better yet, this is done without losing track of the disaggregated elements, and the orchestration can extend across clusters and even to third-party service elements.  Orchestration makes a cluster of white boxes look like a chassis of line cards with a central controlling intelligence, one that’s orchestrated from microfeatures by DNOR.  No matter how large or complex a DriveNets Network Cloud configuration is, or how many white boxes are used, the cluster is connected and managed like one device.

In DriveNets’ Network Cloud, control and data planes are separated, and the control plane is implemented by cloud-native microfeatures.  These cooperate, through DNOR orchestration, to create the trunk/port interface control protocols and the management interface, so instead of presenting a dozen white-box elements as a dozen routers, for example, DriveNets presents them to the rest of the network as one router.

Through orchestration of the control-plane microfeatures, DNOR manages not only how the Network Cloud works, it manages how it looks. Central to DNOR is a cluster-model that defines the initial cloud configuration and is maintained as things are added, scaled, or replaced.  That model is the virtual center of the cluster, controlled by DNOR .  Every step of the lifecycle, from initial configuration to scaling under load or responding to failures, is managed within the Network Cloud by DNOR.

Network Management from a Cluster-model View

The cluster-model view lets DNOR synthesize all the interfaces so that every other router in the network sees a Network Cloud cluster as a single device, and so that it can be managed as a single device.  The model also allows management personnel to parse through the Network Cloud, starting at that single-router view, downward to every microfeature, every container, every white box, every interface.  The relationships between software and hardware, features and services, are fully visible on these deeper management dives, but they never intrude on high-level management tools or practices.

Just as you can dive down to the details within a Network Cloud, you can also climb upward, from a single-cluster view to a view of all the Network Clouds in a network.  This can provide correlated insights into collective network behavior, a view of resource state that’s parallel with traditional management views but integrates a cloud-like collected vision of resources and state.  One view to rule them all—the literal truth.

Impressive Network Insights

The insights available from DNOR and the companion DNOS operating system are impressive; you can get both hardware and software state in detail, KPIs relating to the SLA, alarm and fault indications, fault correlation and root cause analysis, and even suggested corrective actions.  These insights can actually improve reliability and availability and reduce operating costs, relative to traditional monolithic routers.


DNOR orchestration manages each Network Cloud to conform to its own SLA, and it also manages the deployment of new firmware, operating system software, DriveNets Network Cloud software, and even third-party extensions that interact with the Network Cloud through any of DriveNets rich APIs.  This means that extensions to basic connectivity services, such as content delivery features or even 4G/5G user-plane interface features, can be tightly coupled to each Network Cloud and coordinated across all the Network Clouds in a network.

Orchestration Enables Cloud-native

Without orchestration, cloud-native computing couldn’t hope to be efficient, or even usable.  Without orchestration, disaggregated networks are just networks created from separated software and hardware.  That simple model can’t transform networks, but DriveNets Network Cloud, with DNOR 2.0 orchestration, is already doing that, and a lot more, in large-scale carrier networks.  They’ve taken disaggregation not just to the next level, but to the right level.

About the author

Tom Nolle is president of CIMI Corporation, a strategic technology consultancy founded in 1982 that serves the networking and IT industries. He's a software architect and developer by background, leading development activities in early applications in distributed computing, electronic funds transfer and software-defined networking and virtual functions. He provides strategy consulting in cloud computing and advanced development concepts, as well as in related areas of networking. His blog is read by over 20,000 professionals each month.


DNOR Accelerating the transition to cloud-native networks

DriveNets White Paper
Bringing the Simplicity and Visibility of Cloud Orchestration to Network Cloud

Skip to content