Your Network's Edge®
Blog Post
You are here
Zero-Touch Provisioning for uCPE – Part 3
Mar 18, 2019
In part 1 and 2 of this blog series, we discussed the issue of authentication between the uCPE and the different network ZTP entities and explained why and how the use of X.509 certificates brings great simplification to this problem. In this third part, we will touch upon another “painful” topic that is also related to ZTP: Software licensing.
Common software licensing practices
The licensing of software is challenging for a number of reasons:
- Unlike hardware licensing, software cannot always be easily linked to a specific hardware platform (e.g., a device’s universally unique identifier – UUID – or serial number). Furthermore, in many cases the software needs to be dynamically moved from one piece of hardware to another. Hence, there is no traditional anchor point upon which to establish the license.
- In many cases, the uCPE equipment is connected to a VPN-only network and does not have a direct internet connection. This makes it difficult to globally apply online licensing and registration solutions (e.g., such that is used for the MS Windows operating system and other popular programs).
- In many cases, the service provider is not willing to deploy a local license manager, provided by the software vendor, in the network. The reasoning for that is simple. As each software vendor has their own licensing management solutions, the CSP would be forced to host and manage a good number of such local license managers, something that can be very challenging operation-wise. From the software vendor standpoint, this prevents its ability to monitor and monetize the use of its software.
For these reasons, licensing puts uCPE software vendors in a big dilemma. On one hand, the vendors want to closely monitor their licensing and make sure that there is no unauthorized use of the software. On the other hand, the CSP wants the software lifecycle operation to be as simple and without limitations as possible. This situation creates a natural tension between software vendors and the CSPs to whom they sell.
In the uCPE world, software licensing is relevant for the operation system (OS) that is usually installed as ‘bare-metal’ on the uCPE hardware, as well for as the virtual network functions (VNFs) that are installed on top of the OS in the form of virtual machines (VMs) or containers. While there are some subtle differences between all these mechanisms (bare-metal, VMs and containers), the licensing issues discussed here are relevant for all.
Generally speaking, the different software licensing solutions are divided into two groups: Trust-based and Untrusted.
Trust-based
In the Trust-based licensing model, the VNF vendor provides the customer with the means to handle software instantiation at their own discretion, with as many simultaneous installations as they need. In this model, it is the responsibility of the customer to conduct a truthful audit and report software use to the vendor. Thus, the vendor needs to fully trust the customer not to abuse the terms of the license.
Trust-based licensing can be achieved with or without a license key or file. However, if a license key or file is used, it cannot be tied to any runtime variable of the software instance, such as MAC address, IP address, serial number, etc. In addition, in order to address break/fix or migration scenarios, there should be the possibility to install the same license key or file on a new software instance running on different hardware.
A license key/file, however, can be associated with an entitlement level for certain capabilities, e.g., whereby a key is defined for a particular feature set. Because of this, changing the software capability’s entitlement level would require providing a new license key/file that enables the new features. If possible, this should be carried out without the need to reboot the software and impact the service in any way.
A license key/file may be either perpetual or time limited. If time limited, an alert mechanism should be implemented to alert the customer of the upcoming expiration date. In order to extend the license to the next period, a new license key/file is required.
Another option for Trust-based licensing is Utility-based licensing. In this scenario, the software automatically registers with the customer systems to obtain a vendor-provided license certificate. The software will then send periodic usage reports to a dedicated customer server. These reports are basically a log encapsulating information about the customer’s on-going use of the software over time. The customer will use this data to report license consumption to vendors and allow proper software usage audit. No license key/file is involved in software activation, i.e., the same certificate is shared by all software instances.
Untrusted
In untrusted software licensing, a specific software installation always binds to a specific platform “anchor”. The platform anchor may be any of the following, or more:
- Hardware serial number or device ID (UUID/DUID).
- Hardware MAC address.
- Software serial number (e.g., some random string that is generated when the software is instantiated on the platform for the first time.
- Software MAC address (for example: vNIC MAC addresses that are generated on VNF instantiation).
The target, in this case, is that once the software is being installed for the first time, a specific license key/file would be required for activation, one that is dependent on the platform anchor. Hence, with this license model, the customer cannot freely create copies of the software in its network. Rather, for each instantiated copy, the customer would need to get a new license key/file that matches the new platform anchor.
While providing good copyright protection for the software vendor, this approach puts obvious operational difficulties on the customer.
In cases where the target platform that runs the software is connected to the public internet, the license distribution could be achieved automatically between the target platform and the software vendor license server. In such cases, each instantiated software will access the license server and receive its license in a completely autonomous manner (this happens, of course, after getting from the vendor an a priori approval, usually referred to as ‘license entitlement’).
However, in many cases, the target platform is located in some VPN and does not have access to the public internet. In such cases, the automatic license dispatch procedure described above is not applicable and other, less attractive means, need to be used:
- Using some offline method to send, for each instantiated copy of the software, the platform anchor to the vendor and receive, in return, the matching license key/file. This approach is very limited from an operational standpoint and is considered impractical in most real life installations.
- Installing a local software license server, provided by the software vendor, within the customer’s network (usually within the customer NOC). This license server will serve as a “front-post” of the software vendor inside the customer’s network, allowing the software vendor to accurately monetize the software licensing distribution within the customer network. The license distribution can be made completely automatic, between the new instantiated software instance and the local license server. What’s more, this arrangement opens the door for more clever/efficient licensing models such as the “pay per use” (where the customer is only paying, per use, for an activated software, or a specific software function, if it is used) or the “license pool” approach where the customer is buying a fixed number of licenses for software instances working simultaneously and decides in real-time which software instances, out of the overall installed pool, to activate.
In this model, the local license server is connected, either online or offline, to the vendor’s main license server. This connection is mainly used for providing purchased license entitlements to the local server and receiving license use reports from it.
As already described in the previous section, some service providers are not willing to install a local license server in their network. The main reason for this being that this licensing approach would necessitate the service provider to install a large number of vendor license servers in its network (many different software vendors = many license servers). Thus, giving rise, again, to the operational complexity of the entire endeavor.
If I have carried out my job properly, the reader of this blog post can surely appreciate, at this stage, the level of complexity and the contradicting aspirations involved in software licensing in general, and uCPE software licensing in particular. These complexities are the reason that up to this point, software licensing, unlike other uCPE aspects, has not been efficiently standardized and the market today encompasses quite a large variety of different licensing solutions provided by software vendors. ETSI’s Network Function Virtualization (NFV) Industry Specification Group (ISG) is making a bold attempt these days to introduce some order and coherency into software licensing (among other things), but time will tell how successful this will turn out to be.
In our next and final installment, we will discuss RAD’s ZTP solution for uCPE and how security and licensing considerations come into play.
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.