Disaggregated Routing and the Multiservice Network Cloud

You could say that the most fundamental notion of IP networking today is that “routers combine to build a network”. It may be the most limiting notion, too. There are many different models of routers, many different configurations. Some services require special software versions for the router operating system. In the age of the cloud, where we have virtual machines, agile software deployments with scaling and recovery options built in, the router network is starting to look like a stone-age artifact.

That’s an appropriate analogy when you consider the evolution of network services. Almost everything new at the service level depends on features easily deployed in the cloud, but incompatible with a router’s monolithic device model. Routers do indeed combine with other routers to build a network, but what if you want to build many networks, or build services that include special functions or features? The lesson the cloud has taught us is that you need to look at hardware as a pooled resource that can be applied to multiple missions at once. That’s as true for network devices as for servers and data centers.

Multiple Routers, One Shared Physical Infrastructure

From the first, DriveNets offered a “disaggregated” model of a router based on a cluster of white boxes and separate software. That separation is important, but there’s another dimension to DriveNets’ model that could be even more important. Like a cloud can run multiple applications, a DriveNets cluster can run multiple router instances, support multiple discrete and fully separated services, and support third-party applications and features. We need to look at the impact of this second dimension of disaggregation to appreciate the full range of DriveNets’ benefits.It’s pretty obvious that if you’re a network equipment vendor who sells access, aggregation, and core routers, there are differences in the devices that tune them to one of those three missions. Access routers form the edge of the network, where users connect. Aggregation network routers are usually placed in metro complexes to collect traffic, and core routers are of course placed in major traffic hubs. All logical, or so router vendors tell you.Not so. Suppose that you have a major metro site where a lot of users connect, a lot of traffic is aggregated, and there’s a jumping-off point to the core. Three different routers in one place, and despite the fact that there may be a lot of users connecting, there’s limited economy of scale for the access routers, and all these boxes create an operations burden.

Replacing Multiple Physical Routers with Software Containers

DriveNets has a better approach. A DriveNets network router can be partitioned into multiple router instances, and each of those can have any set of characteristics the operator would find useful. For example, a single Network Router cluster could be a set of access routers, an aggregation router, and a core router, all at once. Best of all, any of these combinations could still be managed as a single device even though the instances would be as fully separated as discrete routers would be.

Finally, Scalable Multiservice – Service Instance Abstraction

This same capability lets a Network Router host instances associated with completely different and independent services. Internet routing, mobile backhaul and 5G User Plane traffic, business VPN traffic, IP or VLAN, can all be hosted on a single Network Router. Even the composition of a router instance can be changed dynamically. DriveNets NCFs and NCPs can be allocated among the router instances hosted by a given cluster, and the allocation can be changed to respond to changes in traffic or connection requirements. A single inventory of spare white box routers can serve a whole population of Network Cloud clusters, too.

Another Dimension of Virtualization

How does this all work? DriveNets implemented this highly flexible model by exploiting another dimension of virtualization, the capability to create an abstraction that represents some arbitrary collection of real-world things. Two such abstractions make up the DriveNets model, a Service Instance (SI) abstraction and an InterService Link (ISL) abstraction. You can think of building a cluster as the process of defining the abstractions needed, then populating them with resources.

All the hardware in a cluster supports the same network operating system software, DNOS, and the same orchestration layer, DNOR. All the feature elements, both DriveNets-native and third party, are simply containers on this common, distributed, platform. There are no big monolithic software release packages, no confusing multiple forks in router code to accommodate different feature sets for different missions. It’s agile and expandable, just like the cloud.

Automated Provisioning, Just Like Cloud

There’s no complex provisioning either. The DriveNets model means that, just like the cloud, the allocation of cluster resources to services can be fully automatic and dynamic. Policies control what resource levels are applied, how they change with conditions. The process of resource assignment needn’t be exclusive, either. Multiple services could be assigned to the same ports, with each given a different grade of service. Policies then define how a packet is handled on arrival, based on the service identity.

By separating control and data planes, hardware and software, and by virtualizing both the management of the Network Cloud and the way it’s partitioned into those Service Instances, DriveNets has created the first fully virtualized vision of networking that’s ever been presented.

The same separation lets third-party elements, including service functions developed by the operators themselves, link tightly to the control plane to mediate service experiences without contaminating the basic mission of the Network Cloud.

Building Networks Like Cloud

DriveNets has built the Network Cloud by applying cloud principles to a tight cluster of open white-box elements, preserving low latency and high throughput while adding cloud resiliency, scalability, and resource efficiency. Remember that legacy router network model I talked about earlier? It just might be time to forget it.