Alternative 1 (TOSCA) vCPE Use Case Design ( DEPRECATED )

Owned by DeWayne Filppi
Last updated: Aug 16, 2017
3 min read

In this document I'll document the current approach for integrating native TOSCA CSAR driven orchestration via the ARIA TOSCA orchestrator for the vCPE use case.  While a specific use case was chosen for focus, the philosophy and mechanism will translate to other use cases.

Modeling Philosophy

Without considering the service designer user experience, TOSCA would be inclined to model everything in a deployment.  TOSCA addresses service modeling in essentially the same way as object modeling is approach in software design.  Types are defined that correspond to real or logical entities, and their relationships inform an orchestrator how to coordinate their orchestration (deployment in this case).  So a complete model of any deployment might include internals of ONAP, including AAI, OF, SDNC, APPC, etc...   Modeling to these concepts, however, would require the service designer to understand (and depend on) ONAP internals, which should be avoided at all costs.  The modeling philosophy being used for the vCPE use case (and beyond) therefore only requires a service designer understand the service that is being designed, and not the platform.

Modeling The vCPE Use Case

Given the goal of hiding system implementation details, and using the vCPE use case description as a guide, the following approach uses a combination of SO code and custom plugins for ARIA to achieve the desired ends.

The orchestration of the vCPE use case can be summarized by the ONAP subsystem interfaces required, and the actual model which the orchestrator will interpret to utilize those interfaces.  Follow is each ONAP subsystem, and its integration point for the TOSCA orchestration flow (alternative 1).

SDC Interface

The SDC will push TOSCA CSARs to the SO, which will store them internally for use by the orchestrator.  Currently the SO does not support receiving and storing CSARs, but will for R1.   Artifacts stored in SO (including CSARs) are stored with a type field in the SO database.  CSARs designated for use by the TOSCA orchestrator will be flagged using this field.  This interface is common to all use cases, current and future.

SO BPMN/Adapter Interface

When an orchestration request arrives, a BPMN task handler in the SO will, based on the orchestration type flag mentioned in the SDC Interface, forward the request to an ARIA Adapter.  The ARIA adapter will be responsible for updating AAI (per the use case flow), and commanding ARIA to parse the CSAR file, create an ARIA service using the orchestration parameters received in the BPMN message, and execution the "install" workflow on ARIA service.  The creation of the ARIA service returns a context ID, which will be stored in AAI for future use (running "uninstall" for example) by the adapter.  The adapter will also implement a naming scheme (TBD) for mapping orchestration requests to ARIA services.  ARIA requires that services be given textual names, which could in principle be random, but for system comprehensibility at runtime, should correspond to the context of the request (TBD).

Multi-VIM Interface

The Multi-VIM project presents a conventional Openstack REST API to clients.  As such, a customized version of the ARIA Openstack plugin can be used for the use case.  The plugin encapsulates the Openstack REST API, and provides TOSCA types that correspond to nouns in the API, such as Instance, Router, Network, etc...  A customized version of this plugin, named ONAP MultiVIM plugin, will use an ONAP namespace, and provide additional functionality as needed in the future by Multi-VIM.  See below in "SDNC Interface" for an example of an extension beyond vanilla Openstack.

SDNC Interface

For the vCPE use case, the SDNC needs to be consulted to reserve networking resources.  Rather than requiring a service design be aware of this, and put an SDNC node in every template along with relationships to all network related nodes, the ONAP MultiVIM plugin will automatically reserve and release resources from the SDNC by wrapping networking related code in the plugin.  For example, if an orchestration defines an "onap.multivim.Network" node, the actual lifecycle methods in the type, called by the orchestrator, will contact the SDNC via its REST API, and allocate the resource.  The SDNC itself will not allocate network resources in the vCPE use case, MultiVIM handles that.

APPC Interface

APPC represents VNFs in the model.  The model will provide an VNF base type tied to the APPC API, and subtypes will provide specific configuration for different VNFs.  These APPC types will be provided by an ARIA APPC plugin, that will define a type for each VNF in the model.  The plugin lifecycle code will gather the specific VNF configuration, and use the APPC API to configure the VNF.



The following diagram describes the interactions to implement the service instantiation:





In a separate document I'll describe the MultiVIM and APPC plugin designs.