Genie in a Network (GIN)™ Life Cycle Management Fabric is key to meeting the declarative and model driven core principles of this platform. It consists of the following main features:
A. Model-Driven Lifecycle Manager – replaces the Service Orchestrator as well as the controllers in ONAP with pure TOSCA-based orchestrator. The TOSCA meta-model defines abstractions that are fully aligned with its mission as service orchestration language. It introduces service topologies as first-class abstractions, which are modeled as graphs that contain the components (“nodes”) that make up a service as well as the relationships between these components. Each component can in turn be modeled as a (sub) topology of more fine-grain nodes and relationships. The decomposition is recursive, which allows for fine-grain components. TOSCA types allow for the creation of reusable components, TOSCA requirements allow service designers to express resource requirements directly in their service models to be matched at orchestration time with capabilities of inventory resources and modeled using the same TOSCA meta model. The supported lifecycle management operations are defined on each node using Interfaces and Operations and implemented using Artifacts. TOSCA’s service-focused meta model enables automated general-purpose orchestration capabilities.
The lifecycle management functionality of controllers/sub-domain orchestrators is built around the same service-focused meta model as the master orchestrator. This allows us to turn controllers into domain-specific orchestrators, built using the same orchestration functionality as the master orchestrator, but using domain-specific TOSCA models. The communication between master orchestrator and controllers follows a “decompose and delegate” paradigm. Controllers can further decompose components internally using TOSCA substitution mapping, avoiding the need for monolithic plug-ins. As a result, the “domain level orchestrators” (controllers) in ONAP such as, APPC, VNFC, and SDNC have been eliminated.
Most service lifecycle management workflows have complex dependencies which results in complex sequencing of orchestration steps. The sequencing may be too complicated for humans to get right, orchestration software is better equipped to determine sequencing of orchestration steps based on dependencies represented in service topology. We can bundle service-specific orchestration logic together with service models in a way that can be understood by all orchestrator components. We can also bundle service-specific policies together with service models, all defined using the same TOSCA language.
Since TOSCA specification’s support for workflows and policies is more than adequate for what is needed, we significantly reduce the complexity of the current ONAP implementation which depends on tediously convoluted and full-blown workflow engines like Camunda, and Drools based policy engines to fulfill this requirement.
TOSCA enables us to define all service specifics in one place, that can be understood by the life cycle manager in a service-independent way.
The life cycle manager is implemented using a Golang based microservice and has a REST API for integration with external applications.
B. Model-Driven Analytics – the lifecycle manager uses a common analytics framework consisting of the TICK. One of the key advantages of the lifecycle manager is that the monitoring parameters and associated analytics
defined by service designers can be bundled with the service models. Analytics will include metrics on services, apps, virtual functions, infrastructure, and the network itself. It can be used to collect and display performance metrics, send alerts, participate in closed loop automation, etc.
Typically, the analytics stack consists of a data collector that collects metrics from a VNF, a metrics server/scraper that scrapes the metrics off the collector, a time series database where the metrics are stored, a dashboard to display the metrics customized to the users needs, and finally a data processor to analyze the data which can then be fed to AI/ML tools for providing feedback to the lifecycle manager. In GIN, we are primarily using the TICK (Telegraf, InfluxDB, Chronograf, and Kapacitor) stack for analytics. However, based on our model driven approach we can easily support variations of the analytics stack that allows one to substitute the elements of the stack with components from other popular frameworks like Prometheus and Grafana.
The diagram below shows how the analytics stack fits in a closed loop automation of the common life cycle architecture. The analytics data processor sends data to an AI (artificial intelligence)/ ML (machine learning) tool, which along with policy engine and other applications provides a feedback to the life cycle manager to alter the operation of a service in an automatic way.
C. Catalogs – a persistent store for service models and associated artifacts. Since TOSCA enables us to define models as well as resources in a standard way, GIN has leveraged that to create a model catalog database whose schema is defined in terms of the TOSCA entities. This provides a
big advantage of saving all kinds of models and resources without having to change the schema. It overcomes a big deficiency of ONAP, where AAI schema has to be changed frequently to accommodate new resources that do not fit the current schema. CCI has chosen Dgraph as the graph database of its choice. It is a distributed graph database with a query language that is closely patterned after the standard GraphQL. The service model catalog includes models for services, virtual functions, resources, networks, infrastructure, analytics, policies, etc.
D. Inventory – a persistent store of service instances created by the Lifecycle Management Fabric. Like the service catalog, the inventory schema is also based on the tosca entities which makes it immune to changes in the types of services and resources. It is designed to handle all layers of the service stack (including service, app, VNFs, network, and available clouds instances).
E. Why TOSCA – to fully take advantage of model-driven management functionality, vendors, service designers, and operators must use a common modeling technology to ensure compatible representations of components, services, and runtime management functionality. There are a number of such modeling technologies that are used in the telecom industry. For example, YANG is a data modeling language that is the de-facto standard in the networking industry for defining schemas for network configuration data and runtime state. Most networking vendors provide YANG modules for configuring their equipment, and many internet RFCs have been created that standardize configuration data schemas that can be adopted by multiple vendors. While YANG was designed to model configuration data, some standards bodies have also used YANG for modeling end-to-end services. Those standards use YANG to define the components of which a service is composed as well as the configuration data and runtime state for each of those components.
Unfortunately, given that YANG is strictly a data modeling language, YANG cannot be used to express service-related semantics. For example, YANG does not allow you to specify which parts of the model define service components and which parts define configuration data for those components. That information can only be found in the standards documents that define the services in the first place. Similarly, the YANG language alone can also not be used to define dependencies between service components, or to express how some components can be decomposed using entire other service models. The YANG language does not have support for expressing those semantics in a general-purpose fashion.
Of course, service semantics are a must-have for service lifecycle management. Automated service lifecycle management systems must know which components make up a service, how those components depend on one-another, how instantiation and activation of those components must be sequenced, how configuration information may need to be propagated between components, etc. To avoid having to build service semantics for each service into the lifecycle management system, it must be possible to express service semantics using the service modeling language.
The industry standard for modeling services and automating service lifecycle management functionality is the Topology and Orchestration Specification for Cloud Applications (TOSCA). TOSCA is a domain-specific language standardized by OASIS for describing service topologies and their associated service lifecycle management operations. TOSCA’s focus is the definition of service semantics, which makes it unique in the following ways:
- Whereas YANG documents are trees, TOSCA uses graphs to model services. TOSCA service topology graphs explicitly model service components (using TOSCA nodes) and the dependencies between these components (using TOSCA relationships).
- For each component, TOSCA allows component designers to define the ports through which their components interact. TOSCA introduces capabilities and requirements for this purpose. Capabilities and requirements allow for modular design of reusable components, and they are an absolute requirement for model-driven service integration platforms.
- TOSCA includes data types for defining the schemas of configuration data for nodes and relationships. As such, TOSCA data type definitions are similar to YANG schema definitions. Unlike YANG, TOSCA also supports node and relationship types, capability types, interface types, and policy and workflow definitions. All of those are required for defining service management semantics.
- TOSCA allows individual components to be modeled using their own service sub topologies. This is useful to model how network functions can be disaggregated into collections of finer grain components.
Using TOSCA, it is possible to build general-purpose service lifecycle management systems that rely strictly on the semantics built into the TOSCA language without having to introduce service-specific knowledge into the management system.