Zero Touch Provisioning (ZTP) in DCSG using NiralOS

Zero Touch Provisioning (ZTP) in DCSG using NiralOS

Background

In 5G, densification of Cell Sites would mean a huge number of Disaggregated Cell Site Gateways (DCSG) being deployed in the edge and access. Total number of DCSGs deployed by each Mobile Operator would vary from around 10K to 100K or beyond. Provisioning and maintenance of 100K of DCSG is going to be an uphill task, as skilled staff may not be available at all locations, many of which would be deployed in rural areas.

To make the installation and provisioning of DCSG cost-effective and scalable, Zero Touch Provisioning (ZTP) is a mandatory requirement. This document provides a ZTP implementation methodology for DCSG using NiralOS. Similar approach can be used by other NOS vendors on white box.

Assumption

  1. The back-haul network from DCSG to core is within the Service providers network and is secured. Traffic would not transit into the Internet or another Service Providers Network to reach the Mobile-Core that contains DHCP server, Web server and Controller.
  2. White box hardware uses ONIE bootloader. Similar approach would work with other bootloaders, like uboot.

Target Platform

ONIE compliant White box hardware running NiralOS. NiralOS is a curated, open source and disaggregated Network Operating System (NOS) that can be integrated with any White box hardware to provide DCSG, Access Router or DPI solution. NiralOS is integrable to White box hardware based on Broadcom, Intel, NXP.

Niral Networks is actively working with following open source community to develop NiralOS:

DANOS  Disaggregated Network Operating System – https://www.danosproject.org/
The seed code was contributed by AT&T to speed the adoption and use of white boxes in a service provider’s infrastructure.
DANOS 2005 was released recently – https://danosproject.atlassian.net/wiki/spaces/DAN/pages/320634926/DANOS+2005+Release+Notes
Niral team is actively working with the community. Its contribution includes::
– ISIS support for IPv4 and IPv6
– MPLS VPN Support for IPv4 and IPv6
– FRR 7.3 Integration
– 6PE/6VPE support
FRRFree Range Routing – https://frrouting.org/
FRR has its roots in the Quagga Project.  FRR is an IP routing protocol suite for Linux and Unix platforms which includes protocol daemons for BGP, IS-IS, LDP, OSPF, PIM, and RIP.
FRR latest release – https://github.com/FRRouting/frr/releases/tag/frr-7.3.1
Niral team is working with the community to bring in Telco specific features. Some of Niral’s work includes:
– 6PE/6VPE support
– ISIS VRF Support

Methodology

The ZTP primarily consists of two steps:

  1. NOS Installation

This step does the correct NiralOS image installation over the Mobile Operator’s network into the hardware. It has dependency on the bootloader. We have assumed the ONIE boot loader, which is the de-facto bootloader for white box hardware.

  1. NOS Configuration

This step is post installation of the NiralOS. It kicks in when the NiralOS boots up. The main purpose of this is to keep the NiralOS configuration in sync with the Cloud Controller.

Step 1 – NOS Installation

ONIE supports an extensive image discovery mechanism. The following methods are tried in this order:

  1. Statically configured (passed from boot loader)
  2. Local file systems (USB for example)
  3. Exact URLs from DHCPv4
  4. Inexact URLs based on DHCP responses
  5. IPv6 neighbors
  6. TFTP waterfall

Except the first two options, any of the remaining can be used for network installation.

Figure 1 – DHCP Process

In our setup, we used the DHCP, option 3. The intermediate Router acts as a DHCP Relay Agent and forward DHCP traffic to the DHCP Server.

An HTTP server (apache2) is used to host the NiralOS ONIE image. The HTTP URL of the ONIE image is mentioned as the default-url option in the DHCP configuration. For ISC DHCP Server, the DHCP configuration is as below:

subnet 192.168.10.0 netmask 255.255.255.0 {
 range 192.168.10.10 192.168.10.200;
 option default-url = "http://192.168.10.10/niralos-1908-amd64-vrouter.iso- 
 ONIE.bin";
  option subnet-mask 255.255.255.0;
 default-lease-time 600;
  max-lease-time 7200;
}

In real deployment, different NiralOS images are to be used for different hardware make, model or geography. In such a scenario, one approach is to group the DCSG by their MAC addresses, and provide the corresponding NiralOS image URL for each MAC group. The DHCP Server is pre-configured with a different NiralOS image URL for each MAC group. Server verifies the MAC address and responds to the DHCP requests with the right NiralOS image URL.

Figure 2 – DHCP Transaction

The ONIE parses the image URL and does a HTTP GET REQUEST to download NiralOS image from the Web Server.

Figure 3 – NiralOS Image Download

Step 2 – NOS Configuration

Figure 4 – Configuration Download

This step is performed by a ZTP configuration agent running in NiralOS. The agent is started by a systemd script, at the time of boot. The ZTP agent keeps the router configuration in sync with the Cloud Controller. The communication between the agent and Controller can be REST, NETCONF or any other standard. In the current NiralOS demo, we use REST. The Controller URL is hardcoded in the agent configuration file, as part of the NiralOS image.

The agent detects the first time boot condition and reports it to the Controller along with the MAC address of the router. The Controller looks into its database, allocates a Router ID (RID). The ZTP Agent saves the Router ID. Next the agent requests for the configuration of the RID. On receipt of configuration, it saves the local copy of the configuration and pushes the same into the configuration management system using load command.

Subsequent Reboots

On subsequent boot, the ZTP agent in NiralOS requests the Controller for configuration. If it finds a difference in configuration, the new file is loaded into NiralOS.

Configuration Updates

Controller notifies of any configuration changes to the ZTP agent. The agent downloads the configuration, verifies with its local copy and loads the new NiralOS configuration.

Next Phase – Secured ZTP

The next phase would be to support RFC 8572 (Secure Zero Touch Provisioning) that covers the security aspects of ZTP. However, it needs changes in the ONIE boot-loader needs to be supported by the White box hardware.

Leave a Reply