Zero Touch Provisioning ZTP is even more critical for Disaggregated Networks running on White Boxes

Service Providers Need a Simple Setup for ZTP

At home, I have a single small DSL Router that I usually replace every few years. When it comes time to replace, I order a box from a well-known vendor online. The box is dispatched directly to my place or the local post office. I open the package, connect the wires as described and go through an automated process, guided by the software that comes with the box. It’s very simple. Unfortunately with the current network model, large communication service providers (CSPs) have no choice than doing some manual interventions when deploying equipment in their networks. Moreover, they need to maintain thousands of routers, switches and other devices, expanding, replacing and renewing devices on a daily basis. With network capacity expected to double every couple of years, CSPs need to support the (exponential) increase in traffic driven by regular consumer consumption – from watching Netflix shows to medical monitoring and soon from autonomous driving. CSPs can’t tolerate a manual process for deploying equipment in their networks anymore. Normally a large CSP has its own operational process for ordering, shipping, provisioning, configuring and activating their network equipment. Hardware vendors need to support ZTP in one way or another to automate deployment processes – regular appliance vendors generally ship their products already loaded with software and firmware. It is even more important for white box-based solutions where the software arrives from a software vendor and should be loaded into the white box somewhere within the operational chain.

White Boxes Add Complexity to Network Operations

When it comes to white boxes, the vendor that ships the box is typically not the one that provides the software or the service that runs on it. Each white box vendor ships its product with a basic software. How would the CSP load the software into the white box? What if the solution is composed from a cluster of white boxes and all must have the same software version? Also, should the CSP trust the “add-ons” it might get with the white box? How would that impact the ZTP process? What about possible security breaches? These are the key challenges for a disaggregated solution. (Many may also say that these security issues are true for a single vendor solution, since the components and sub-systems typically come from different manufacturers.) The key drivers for using white boxes are the flexibility and cost efficiency they offer CSPs, as well as for avoiding vendor lock-in. Why flexibility? CSPs can choose from a variety of vendors thus optimizing their supply chain with the ability to negotiate better prices, consider different software options, etc. The more flexibility that is introduced to CSP networks, the more that the networks will grow in complexity (more device types, more combination of hardware and software, more versions to maintain), requiring greater orchestration and higher levels of security. Furthermore, CSPs need to operate multiple types of white boxes, maintaining diverse flavors of hardware, firmware and software versions, and ultimately ensure that they all operate as an integrated system.

The need for ZTP in Disaggregated Networks

As a child, my mom used to tell me: “wash any new piece of clothing you buy, you don’t know who touched them and what it might bring into your home.” The same is true with white boxes. Some CSPs may choose to “wipe” the white boxes they use before potentially compromising the security of their network. This additional step exacerbates complexity, underscoring the need for ZTP, while driving greater attention to the ZTP process itself.

A cloud-based solution overcomes the ZTP operational challenge

How did we at DriveNets overcome these ZTP scale and security challenges? We found that a cloud-based system that is easily accessible by all the different ecosystem parties would be the most secure and convenient solution as a DriveNets Network OS installation platform, and therefore would be a part of the delivery chain. The goal of this cloud-based system is to make sure that white boxes get authenticated and ready for DriveNets Network OS deployment automatically and at scale. DriveNets Network OS deployment takes place within the CSP premises. How does it work? Typically, large appliance vendors partner with one or more Value Added Resellers (VAR) to resell, prepare and ship devices to the CSP’s data center. The VAR plays a key link in the chain of operations. The diagram below describes the white box journey from the vendor to the CSP using DriveNets Network Cloud. Some would say that the role that ZTP plays is only at the last mile inside the SP network, but in reality ZTP could start earlier at the VAR premise to improve the automation inside the CSP network. The VAR process:

1. Receives the white box pre-loaded with vendor’s Network OS installer environment – usually based on an industry standard called the Open Network Install Environment (ONIE)
2. For extra security, “wipes” all software from the white box’s hard drive.
3. Installs the secure DriveNets’ Network OS installer environment based on ONIE
4. Authenticates the box and installs the basic OS software including a DriveNets Network OS installer agent through the DriveNets’ cloud-based Network OS installation platform.

The white box is then ready to receive the relevant certified DriveNets Network OS software and become a working box. It is carried out in two steps:

1. The white box is sent to the CSP. Once physically mounted within the CSP’s network, it automatically connects and registers to the CSP’s Network Orchestration application and gets provisioned with the right DriveNets Network OS software (“calls home”).
2. Once the orchestrator creates the cluster, the other white boxes within the same cluster are automatically provisioned with the matching DriveNets Network OS software.

The whole ZTP process is simple, smart and secure for both CSPs and VARs. This no longer means provisioning router components – individual white boxes – but the whole router as it can be composed of dozens of white boxes with different functions (the actual number depends on the required capacity). From the software perspective, it is a pretty sophisticated solution, where a single white box or a cluster of dozens of boxes act as a single router. At DriveNets, we looked for a technology that could deploy and manage our clusters. It needed to ensure that all cluster members are functioning, connected correctly, report their status and – when needed – are automatically replaced by a new box, providing smooth redundancy and in-service upgrade. This was not only a deployment challenge, but also a huge maintenance challenge (but that’s another story).

Keeping everything in order with orchestration

In the DriveNets solution, the main components for orchestration are:

• Global DriveNets Network Orchestration system (G-DNOR) – a secure, cloud-based Network OS installation platform for preparing DriveNets Network OS (DNOS) deployment in the CSP premises – configuring hardware, installing the basic OS software and DriveNets’ Network OS installer agent
• DriveNets Network Orchestration system (DNOR) – a comprehensive orchestration and life cycle management application for provisioning, operating, and troubleshooting DriveNets Network Cloud elements. DNOR is installed in the CSP’s premises. DNOR is designed to address disaggregated network management challenges and provide a unique automation toolset to orchestrate next-generation hyper-scalable networks in a simple and user-friendly manner.

DNOR offers ZTP for Network Cloud deployments, configuration provisioning, and life cycle management operations, such as software version control. DNOR orchestrates the process and carefully monitors every step, providing alerts for any inconsistency and guiding the operator in case a manual intervention is required. With DNOR, administrators follow-up on the deployment process, waiting for a “green” indication to happily start injecting a huge amount of traffic into the DriveNets router. You can probably tell that I find this entire process fascinating and incredibly smart! Now, just to wrap up. The wide adoption of white boxes has impacted the ZTP process, making it even more essential than ever for simplifying the deployment process. Why?

• Disaggregation and distribution – the ZTP (zero touch provisioning) process provisions all router components, turning them into a single router entity (distributed and disaggregated over multiple physical white boxes).
• Scale out – once the cluster is active the CSP can expand it to deliver more capacity, and the scale out process should be zero touch.
• Security – service providers can’t compromise on security. Networks must be safe. ZTP is critical since it deals with the white box “cleaning” phase.

For CSPs, it’s a whole new network and not a single box anymore. To keep the music playing smoothly across the network – all the router parts need to work in harmony. The ZTP process brings order to this very complex system.