License based SLAs - sonata-nfv/tng-sla-mgmt GitHub Wiki

Licensing

Apart from the well-known advantages that SDN is bringing to the spectrum, Software Licensing is changing also, reflecting on how organizations and individuals use software. 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 is any procedure that lets a vendor or user, purchase, install, and use software (i.e. Network Services) in accordance with a licensing agreement. 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.
Thus, an important addition to the SLA Manager component of 5GTANGO Service Platform in release 5.0, is the introduction of Licensing into the SLAs. Specifically, an interconnection of Licenses with SLAs was introduced, in order to introduce SDN-enabled licenses in a more efficient a flexible way. In a nutshell, the Licensing Mechanism into the 5GTANGO SLAM associates an SLA to a costumer, by using business metrics, and at the same time link them to NS Licenses. Finally, the NSs are being instantiated, with verified Licenses, and orchestrated through the MANO. It is worth mentioning that licensing is provided "as a service” and it is included into the provided SLAs.

Licensing Model

SLA Manager provides 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. The model provides three types of licenses: a) trial, which supports limited time of trying the desired NS before license purchasing, 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, meaning that the end-user is allowed to deploy the NS with infinite number of instances and for an unlimited period of time.
  • Trial License: The Trial License refers to the NSs which end-users can try before they buy. Trial Licenses offer an effective way to distribute an unlimited number of time-limited deployment of the provided NS, with mandatory registration. 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. When the trial period expires, the user cannot deploy the NS any longer, leaving the option to purchase the full License. Apart from the constrained period, the Trial License has a limited amount of free NS instances that the end-user can have it activated at the same time.
  • Private License: The Private License refers to unlicensed NS descriptors, outside the scope of copyright protection, non-distributed, non-licensed and handled as internal business “trade secret”. 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.

License Service Level Objective

An SLA Template Descriptor includes an object which define the type of License for the Network Service described, in form of Service Level Ojective (SLO). For a full SLA Template example, including the License SLO you can check here. The License SLO includes the following:

  licenses:
    service_based:
      service_licence_type: Trial  # Public|Trial|Private
      allowed_service_instances: '10'  # The number of allowed NS Instances based on the license
      service_licence_expiration_date: '2018-12-14T11:35:10Z'  # The license expiration date

Workflow

In this section we are going to describe the end-to end workflow for establishing licenses through SLAs and enforce them after the NS instantiation. On the Customer side, we have the Portal along with Gatekeeper that implements the communication of the outer world with the inner components. The Gatekeeper awaits a request for an SLA creation in order to trigger the process. 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.
  • Step 2: The Gatekeeper promotes the request to the SLA Manager, with the necessary authentication details.
  • Step 3: The Licensing Mechanism (into the SLAM) receives the necessary parameters (i.e. license type, allowed instances, license expiration date) among with the customer’s authentication details, and stores a license record into the SLAM Correlation Database. Additionally, it sends the license information as an additional SLO to the SLAM in order to include it into the SLA Template.
  • Step 4: The SLAM receives the license SLO, and the SLA parameters (SLA name, QoS SLOs, SLA expiration date etc.) while it formulates the SLA Template. Additionally, it stores a record into the Correlation Database regarding the corresponding NS and the created template.
  • Step 5: During this step, the customer requests through the Portal a NS instantiation, specifying the desired NS and a specific SLA, with a license attached to it.
  • Step 6: The Gatekeeper promotes the request to the SLAM.
  • Step 7: At this point, the Licensing Mechanism is responsible to validate if the customer is allowed to instantiate the service based on the selected SLA and the attached 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 Mechanism 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 Mechanism 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 Mechanism 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.