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
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.
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 | FRR |
Disaggregated Network Operating System – https://www.danosproject.org/ | Free Range Routing – https://frrouting.org/ |
Methodology
The ZTP primarily consists of two steps:
- 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. - 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:
- Statically configured (passed from boot loader)
- Local file systems (USB for example)
- Exact URLs from DHCPv4
- Inexact URLs based on DHCP responses
- IPv6 neighbors
- 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
DCSG-1 | Interface connected to 5G Base station is configured as VRF Blue Interface connected to Enterprise Brach office is configured as VRF Brown |
DCSG-2 | One of its interface is connected to Enterprise HQ and is configured as VRF Brown |
CR-1 | Interface is configured as VRF Blue for 5G traffic Similar other interfaces are configured with VRF for 4G traffic, Home traffic etc. |
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.
