SLA Workflow - sonata-nfv/tng-sla-mgmt GitHub Wiki

In order for a network service to be deployed in the service provider’s infrastructure, several steps should be done with regards to the required quality that should be agreed in the final SLA Agreement with a License attached.

SLAM Workflow

Definition of an SLA Template with License Information

  • STEP 1: Check if there is a NS in the 5GTANGO Catalogue. The oparator may define many SLA Templates per Network Service. Each Template should have a different name or/and diffrent version.

  • STEP 2: Select the desired NS (get the appropriate ns_uuid) in which an SLA Template will be applied.

  • STEP 3: Create an SLA Template by specifying:

    • Basic SLA information
      • a template name
      • a template expiration date
      • a guarantee id - refers to an id from a configuration list of service level guarantees. The oparator may select one (at least) or more guarantees.
      • an expiration date for the SLA
      • the provider name (e.g. Telefonica)
    • License Information
      • the license type (e.g. public)
      • the allowed network service instances
      • the license expiration date
    • Deployment Flavor information
      • select through the available deployment flavours specified for the selected NS, in order to include it into the SLA, for better QoS assurance.

  • STEP 4: The SLA Template is cretated. The correlation between the NS and the SLA Template is stored in the SLA Manager's database and available through the Management API endpoints

NS Instantiation & definition of associated SLA

  • STEP 5: When the SLA Manager receives a message in the RabbitMQ that defines a succesfull instantiated NS (`status=READY'), a correlation between instantiated NS - customer - selected SLA is created. Additionally a License record is created for the specific customer.
  • STEP 6: The SLA Agreement and the corresponding License is available and stored in the SLA Manager's database.

NS monitoring and SLA violation alert

  • STEP 7a: Once an SLA in attached to an instantiated NS, the SLA Manager is responsible to send to the Monitoring Manager some rules to monitor appropriate the metrics guaranteed in the SLA.
  • STEP 8a: When a metric exceed the defined rule, the SLA Manager consumes the appropriate message from the Monitoring Manager.
  • STEP 9a: If a metric is exceeded the SLA Manager make an alert to RabbitMQ that indicates which SLA was violated, when and which reason caused the metric to fail.

License validation

  • STEP 7b: At the same time, when the agreement is created, the SLA Manager is responsible to validate the License attached to the specified customer. To do so, there is a listener, that validates the license every24h.
  • STEP 8b: When a license expires, the SLA Manager automatically terminates the corresponding SLA, and at the same time requests the NS termination.

NS termination & removal of associated SLA

  • STEP 10: Once a NS is terminated, all the associated SLA (the agreements, not the templates) are removed from the SLA Manager's database. In addition, the Monitoring Manager gets informed, in order to stop monitoring the metrics for the SLA that is associated to the terminated NS. Also, all the associated Licenses de-activate.