RAD is a global leader for telecom access solutions. As an industry pioneer for over 40 years, RAD reliably supplies worldwide communications service providers and critical infrastructure operators with best-of-breed Ethernet access devices, industrial IoT gateways, 5G xHaul, and Operational WAN solutions. Offering always-on connectivity from anywhere, along with data-driven, AI-powered actionable insights, RAD is distinguished for its supply-chain stability, which outsteps the market in delivery times. Founded in 1981, RAD serves as the anchor of the $1.6 billion RAD Group, an umbrella of independent companies that develop diverse networking and data communications solutions.
Contact

Contact Us

This information will be used according to our Privacy Policy

Scroll to top of page

You are here

   

Zero Touch Provisioning for uCPE – Part 4

Mar 25, 2019

In parts 1, 2 and 3 of this blog series, we discussed the issues of security and licensing as they relate to ZTP. In this last installment, we will review the RAD ZTP solution over public networks. While reviewing it, we will be able to see, step by step, how it addresses security and licensing.

To DHCP or Not to DHCP?

When a network device boots up for the first time, the first step is to have it connected to its network management system (NMS), usually residing in the service provider (SP) network operations center (or NOC). Once the device management is established, all life-cycle operations, as well as the service itself, can be performed. This step is usually referred to as “call-home.” As already discussed at the beginning of Part 1, Zero Touch is a system that allows a network device, upon its first boot, to call home. In order to do that, the network device needs to receive some basic information, such as: The IP address of the NMS, means of connectivity to the NOC and any relevant information that is needed to secure the connection.

When a network device boots for the first time, it will usually look for a “nearby” DHCP server to get its IP address, as well as other IP-related settings such as its IP subnet, default gateway and DNS settings. Through this DHCP server, the device could also potentially receive the required call-home information. However, in order for that to happen the DHCP server must be controlled by the SP itself, so that the relevant call-home information could be installed on it in advance. Indeed, if the device is located within the SP VPN, and the DHCP server is owned and controlled by the SP, this would be trivial. On first boot, the device connects to the DHCP server to receive its IP as well as its call-home settings. This is usually done via a standard DHCP option that redirects the device to another TFTP server, from which it can obtain the call-home information that was planted there in advance. This procedure is sometime also referred to as on-net ZTP.

It is the cases where the device is not located within the cozy boundaries of the SP VPN (e.g., when it’s connected to the internet) that require special attention. Now, the local DHCP server is out of the SP control (e.g., when it belongs to the internet service provider), so the call-home information must be provided to the device in a different way. This use case is also referred to as off-net ZTP and will be the focus of our discussion here.

A step-by-step description of off-net ZTP using a RAD uCPE

Before the device can be sent for installation at a remote location, it must be “staged.” The staging process usually includes the installation of the device software (e.g., the uCPE operation system) on the bare-metal hardware as well as any other software images that would be needed later, such as VNF images (see Step 1A figure below).

Step 3: Backstage ZTP preparation at the NOC

Step 1A: Device staging – bare-metal vCPE-OS installation

 

During the staging process, we will also give the device its default first-boot configuration. In other words, we will instruct it exactly what to do when it boots for the first time (e.g., obtain IP settings from a local DHCP server, get a bootstrap (BS) server IP address based on preconfigured URL, etc.). In addition, security certificates will be installed at this stage if needed.

The staging process can take place either by the device vendor as part of the manufacturing process, or by the SP itself in its staging facility. Once completed, the device will include all the required entities that would allow it to successfully perform off-net ZTP (see Step 1B in the figure below). It can be then stored in the SP warehouse until shipment.

Step 1B: Device staging - installation of secured entities and minimal staging configuration

Step 1B: Device staging - installation of secured entities and minimal staging configuration

 

For installation, a technician would just need to plug the device to power, physically connect it to the network (via a network cable or a SIM card for LTE connectivity) and report to the SP’s NOC that a device with a given UUID was successfully installed on location.

Step 2: The technician installs the device @ customer premises

 

Step 2: The technician installs the device @ customer premises

 

Once a device is shipped for installation at a customer location, the SP starts building the ZTP artefact for this device. The ZTP artefact is a file that comprises all the information the device needs in order to call home. The ZTP artefact is prepared in advance by the ZTP configuration server at the NOC and, once the technician reports the successful installation and provides the relevant device UUID, it is finalized and placed within the bootstrap server in a location reserved only for this device. The bootstrap server is basically a storage server that hosts a device’s ZTP artefacts, having a public IP address that can be accessed from anywhere using plain internet access.

Step 3: Backstage ZTP preparation at the NOC

Step 3: Backstage ZTP preparation at the NOC

 

At this stage, all the “board pieces” are set for the main event. Once the device boots for the first time, it would connect to the local DHCP server and obtain a public IP address, as well as its IP and DNS settings. This will allow the device to have internet IP connectivity. Next, a DNS query for the BS server’s IP address is performed and once obtained, the secure TLS connection to the BS server, based on X.509 certificates, can be set. Once securely connected, the device can download the ZTP artefact from the BS server and reboot. After reset, the device will now have its call-home configuration in place.

At this point, the device’s software has still not received its license. Hence, an automatic grace period is usually provided by the OS, to allow all device operations until a connection to the NOC is established.

Step 4: The device connects to the Bootstrap server

Step 4: The device connects to the Bootstrap server

 

Based on the call-home configuration, the device forms the secure VPN connection to the SP’s NOC (again, based on X.509 certificates) and connects to its NMS. At this point, the device will also receive its permanent license, if needed.

Step 5: The device opens a secure VPN connection to the NOC

 

Step 5: The device opens a secure VPN connection to the NOC

 

This last step also brings this blog series to its end. Throughout its four chapters, I was trying to make the reader aware of the various challenges and complexities involved in off-net ZTP of uCPEs. While the information provided primarily reflects RAD’s experience, the general guidelines are considered common practice for many uCPE and uCPE OS vendors.


 

< Blog Home

About RAD's Blog

We’ll be blogging on a wide range of hot topics affecting service providers and critical infrastructure network operators. Our resident experts will be discussing vCPE, Cyber Security, 5G, Industrial IoT and much, much more.

   

What would you like to do?