You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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.

  • No labels