Architecture - sonata-nfv/tng-sla-mgmt GitHub Wiki

The SLA Manager's internal architecture is shown below.

SLA Manager Internal Architecture

SLA Template Management

The SLA Template Management component is responsible for receiving all the appropriate information from different stakeholders and formulate a Service Level Agreement in an efficient way. In addition, it is responsible for the mapping of high-level requirements to low-level resource attributes, through a Mapping Mechanism.

  • SLA Template Generator: firstly, creates SLA templates for the Provider, and secondly creates the final SLA itself.
  • SLA Mapping Mechanism: mapping between the high-level requirements described by the end-user and the low-level requirements (deployment flavors) described by the NS developer, providing efficient Q.
  • SLA Licensing Mechanism: included licens einformation into an SLA Template, as an additional Service Level Objective (SLO), corresponding to a specific NS, specifying also the number of allowed NS instances

SLA Information Management

The SLA Information Management component takes place during the NS run-time, and is responsible for obtaining historical monitoring data, analyze them and make any adaption if necessary to the SLA mapping results.

  • SLA Monitor Analyzer: Compare the QoS parameters from the Mapping Repository, with the computed monitoring measurements and check if there is any violation in order to achieve optimization.
  • SLA Violation Mechanism: responsible to ensure that the newly deployed NS would not violate the corresponding SLA upon instantiation, while it successfully fulfills the signed business needs.
  • License Validator: Validates the Licenses of the instantiated SLAs, every 24h.

SLA Correlations Repository

The SLA Correlations Repository is responsible for storing and managing all the necessary correlations, between end-users (i.e. customers), 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, along 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.