Introducing Licensing throughout SLAs in NFV Environment

. Software licensing is changing how organizations and individuals use software. Globally, technical and economic needs affect licensing in many ways and thus creating licensing models and techniques that reflect and serve organizations’ needs, becomes an increasingly challenge in the Network Function Virtualization concept. While NFV continues emerge, it also becomes increasingly important to monitor and manage software licenses. Therefore, in this paper, a license-based architecture is introduced which aims at linking the Network Services with license models throughout SLAs. Specifically, we have introduced an interconnection between license models and SLAs, in which we aim at an efficient and flexible service orchestration in a beyond MANO SP.


Introduction
Telecommunication networks are an essential part of any society's infrastructure as millions of people rely on the services offered by today's telecommunication providers, expecting the arrival of commercial 5G networks to bring new capabilities. Network Function Virtualization (NFV) is expected to be the key enabler for agile network management in the upcoming 5Gnetworks, as it will allow optimized service management through softwarization and virtualization of network components [1]. One of the leaders of the group of network operators, who introduced the NFV concept, mentions that software licenses will play a significant role in the economics of NFV [2]. As network operators push forward with virtualization in the hybrid network environment that currently exists, software license management arises as a primary challenge. [3]. Licensing models and monetization of different Virtual Network Functions (VNFs) and Network Services (NSs) enable better service elasticity and better utilization of network resources, while it also starts getting attention from many companies like Google, Yahoo, Cisco and others [4]. For enterprises that rely on software to maintain a market share, the software licensing model can strongly influence the return on software investment. Software licensing aims to protect both the vendor's investment by minimizing the risk of hard piracy and the enterprise's investment by minimizing the risk of auditing fines from soft piracy [5]. It is important to note that a declarative license approach is commonly used on the B2B market, particularly with telecommunications operators. This involves entrusting the software licenses with the task of controlling the use of the software in subject to the terms of the license, classifying the rights of use and the identified limits. Telecommunication operators are used to managing their software licenses and have a dedicated business process called Software Asset Management (SAM), that needs to be adapted to fit with automation processes orchestrated by NFV Management and Orchestration (NFV-MANO).
To address the aforementioned challenges, in this paper a license-based architectural approach is described, that allows efficient NS license management, in a virtualized SP. We propose an interconnection of licenses, with Service Level Agreements (SLAs) in order to introduce NFV-enabled licenses in a more efficient and flexible way. presented architecture is It is worth mentioned that the presented architecture is part of the SONATA (powered by 5GTANGO) Service Platform which bridges the gap between business needs and network operational management systems [6].
The rest of this paper is organized as follows. Section 2 presents the related work on the field of software licensing. Section 3 introduces the proposed license-based architecture, while Section 4 presents the license model followed in our approach. In Section 5, an end-to-end workflow is presented in order to describe in detail the overall process. The paper closes in Section 6 with some conclusions and future thoughts of the presented work.

Related Work
A substantial amount of research has been undertaken to investigate the challenges the developers face with the different approaches for using, or re-using, software, especially in the context of VNFs and NSs. Further complicating the situation, not all of the ways in which a developers may wish to make use of open source code may be allowed by the license applied to that code and the way in which the code is used may affect the resultant license of the NS being built. Therefore, licensing of VNFs and NSs is a complex task that need to be addressed at all the different layers of NFV concept. With new license technologies like Cisco Smart Licensing [8], licensed products can be activated, and entitlements redeployed without handling special software keys or upgrade license files Service providers, network vendors and their customers would need the capabilities enabled by new licensing technologies to deliver on the promise of the intelligent, cloud-based and software-defined network and fully realize their benefits. As stated in [9], software licensing is changing how organizations and individuals purchase and use software. Thus, the authors make a general introduction on the different licensing models while they also describe how organizations and individuals can benefit from them. Such common licensing models are for example a) Packaged: Single license purchased for a single user or machine., b) Perpetual: Permanent licenses purchased upfront, c) Trial: Users are able to try the software before purchasing, d) Server: Number of processors running determines number of licenses purchased . It is worth mentioning also the fact that ETSI NFV has published the "Report on License Management for NFV" [10]. It documents the features required to be implemented within the ETSI NFV architectural framework to support NFV license management. These features will enable any combination of commercial license management without the need for proprietary license management mechanisms. Henceforth, the authors illustrated the composability of service licenses by creating a composite service license, that is compatible with the licenses being composed. Furthermore, in [11], the authors compared SLAs and service licenses while they also proposed the phases of a service license during its life span. To make the discussion more concrete, they illustrated the proposal of a service license life cycle with a meteorological case study. At the same time, in [12], the authors have realized the interest for the integration of license management mechanisms into the software defined systems and architectures. They proposed a solution that exploits all Service-Oriented Architectures (SOA) key characteristics, trying in the same time to resolve the restrictions and to confront the weaknesses of the current License Management systems. They also defined the roles emerging from the suggested architecture and presented new business models and market opportunities.

License Based Architecture
This section describes the proposed license-based architecture, taking advantage of the components implemented into the SONATA (powered by 5GTANGO) SP. The SONATA (powered by 5GTANGO) SP brings, among others, the SLA Manager and increases its abilities with a Licensing Manager, a component that allows the user to obtain NS licenses and verify them during the NS instantiation. Figure 1 depicts the overall architecture) that is going to be described in this paper. The license-oriented architecture consists of a) the Portal, b) the Gatekeeper, c) the SLA Manager, d) the Licensing Manager e) a Correlations Database and e) the MANO Framework.

Portal
The proposed architecture is consisted of several components. In order to be accessible to the end-users, a unified Portal was implemented as a Web User Interface (WUI). The Portal is divided into sections that include Network Services, SLAs, Licensing Management, as well as an Operation section, for NS instantiation management. The main role of the Portal is to help the SP owners and operators to create business-oriented SLAs for QoS provisioning. Moreover, the Portal promotes the interconnection of the aforementioned SLAs with the desired licenses, known by the developers entered the Portal and the creators of the SLAs.

Gatekeeper
While the Portal is the main web interface interacting with the SP end-users the Gatekeeper is the entry point, controlling who attempts to access the inner components (i.e. SLA Manager, Licensing Manager, MANO) and the privileges to do so. The Gatekeeper exposes API endpoints for QoS management through efficient SLAs, as well as of licenses for each NS that is going to be deployed in the SP. The Gatekeeper validates and forwards requests, for managing SLAs, to the SLA Manager (subsection 3.3) and for creating licenses, to the Licensing Manager (sub-section 3.4). The Gatekeeper also serves an important and active role in implementing the MANO Framework communication interfaces (sub-section 3.6).

SLA Manager
A key objective of NFV technologies is the provision of QoS guarantees. These guarantees are reflected to the requirements emerging from the agreements between the customers and service providers. At this point a question arises, regarding what exactly is an SLA. An SLA is a contract between the service provider and the customer, which underlines each party's responsibilities while at the same time defines the performance standards that are to be met by the provider [14]. The proposed SLA Manager can support a) Definition and advertising of the capabilities of network operators in SLA Template forms and b) Agreements creation upon a NS instantiation [16]. licensing as a different kind of a SLO, leading to two different kinds: a) service guarantee SLOs and b) licensing SLOs. On the other hand, the Information Management phase starts during the NS instantiation, incorporating the SLA instance creation and the enforcement of the licenses. The SLA instance is an enforced SLA template with the instantiation information, and the relevant licensing information, that refers to the linked NS instance and the customer's information.

Licensing Manager
In the various functional domains of NFV-based network architectures, software licenses apply. In the current work, we are focusing on the software licenses for VNFs and NSs. Thus, taking into consideration the emerging NFV technologies, there is a need to include in the SLA contracts licensing information for the corresponding NSs. It is important to point out that the SLAs are business-oriented documents. Therefore, the licenses included in them, do not tend to be aligned with specific amount of resources. The licenses, as specified into the SLA Templates, focus mainly on how many scales can be used, based on the "signed" license type. It is worth mentioning that licensing is provided "as a service". The provided licenses are created per customer, and due to the fact, that are included into an SLA Template, as an additional SLO, each license corresponds to a specific NS. In this context, the Licensing Manager adopts a service-based licensing model, which links a license to a specific customer and an instantiated NS, by specifying also the number of allowed NS instances. Finally, the instantiation operation takes place with verified licenses, and orchestrated through the MANO.

Correlations Database
At this point, it should be pointed that all the presented components follow a micro-service-based architecture, therefore, a database was used in order to keep runtime information of network services, SLAs and licenses. Specifically, it keeps track of all the correlations between the generated templates and the linked NSs. At the same time, agreements information is also located in the Correlations Database, among with the end-user's authentication detail coming from the inter-communication with the Gatekeeper. Finally, the database stores the correlations between the end-user (i.e. customer), the corresponding licenses, and the number of successful instantiations, resulting from the successful placement of the service through the MANO Framework.

MANO Framework
On the bottom of the proposed architecture lies the MANO which is responsible for the orchestration and full lifecycle management of hardware resources and VNFs. In our case though, we are taking into account a customized MANO Framework, implemented into the SONATA (powered by 5GTANGO) SP, which allow the operator and the service developer to join forces in managing their lifecycles to fulfill SLAs and manage properly the corresponding licenses [18]. It exposes an API where other components, like the SLA Manager, can request lifecycle events, providing at the same time licensing information, that could be mapped to a particular amount of resources, which will be validated eventually by the Licensing Manager. As a result, MANO will use the license information for the NS instantiation and operation.

Proposed License Model
The model provides three types of licenses: a) trial, which supports limited time of trying the desired NS before license is purchased, b) public, which comes with no instantiation restrictions, and c) private, which specifies as mandatory the purchase of a license before instantiating a NS.
• Public License: The Public License refers to an open source NS, which the descriptor (i.e. source code) is available to the end-users for instantiation free of charge. As previously mentioned, the Public License comes with no instantiation restrictions. • Trial License: The Trial License refers to the NSs which end-users can try before they buy. Once the end-user in registered and selects to instantiate a NS with a Trial license included in the selected SLA, he or she activates the license "silently", and can use it for the time period specified in the SLA. Apart from the constrained period, the Trial License has a limited amount of free NS instances that the enduser can have it activated at the same time. • Private License: In the proposed architecture, the Private License means that the customer needs to buy a license before instantiating a service. Additionally, this type of license specifies the number of allowed simultaneous instances per customer.

End to End License Workflow
In this section, it is described the end-to end workflow for establishing licenses through SLAs and enforce them after the NS instantiation. On the Customer side, there is the Portal, along with the Gatekeeper. The Gatekeeper awaits a request for an SLA creation in order to trigger the process. The sequence of interactions are depicted in the sequence diagram of Figure 2. In detail, the steps include the following: • Step 1: The workflow is triggered by the SP owner who enters the Portal and starts the creation of an SLA. The SP owner gives the mandatory parameters for the SLA creation (e.g. QoS parameters, expiration date etc.), selects the corresponding NS and the desired license type (i.e. public, trial, private). In case the SP owner select a trial or private license, it is mandatory to select the allowed instances as well as the valid period of the license.   ─ In case the customer has selected an SLA with a public license, the instantiation request of the service is promoted to the MANO with no further action. ─ In case the customer has selected an SLA with a trial license, the Licensing Manager needs to validate it. If the license has not been expired, or not exceeded the allowed instances is then promoted to the MANO. Otherwise, the request terminates, and the customer is asked to purchase the license in order to continue. ─ In case the customer has selected an SLA with a private license, once again the Licensing Manager needs to validate it. During the first instantiation of the service, the customer is prompted to the Portal in order to buy the corresponding license. In case the customer has already bought the license, the Licensing Manager check the license expiration date and the allowed instances, and if they all are valid, the instantiation of the service proceeds. • Step 8: If the license is valid, the MANO receives the instantiation request, and continues with the NS placement and deployment.

Conclusions
In the presented architecture, we consider a licensing model, taking into account both the cost constraints of the NS software and the allowed instances per customer, towards a more efficient scaling concept. In order to do so, the presented approach links the provided NSs to a selected license model, which is included into a signed SLA in an easy and flexible way. Even though the presented approach is still work in progress, the entire workflow described in the above paragraphs can be executed on a regular laptop and the code of all involved software components as well as their install instructions and documentation are available on the project's official web site [16], as well as on GitHub [17]. The next step will be to motivate service providers to engage in this critical next phase and begin developing product roadmaps to support the management of NFV licenses with the features and scalability required for telecommunications operations. In this way, the proposed architecture will be also evaluated by be tested in the NFV space.