Release Amsterdam Gating Use Case

Draft in progress

Goal:

The goal of gating use cases is to define a set of functional features, which cover only ONAP platform directly related features of R1 (VNF onboarding and service creation, service provisioning, closed loop, multi-VIM/Cloud, etc),  and to ensure that it is feasible to implement those features within the release time frame.

Criteria for Gating Use Case:

• It covers both design time and run time environments.
• All ONAP major modules should be used
• All major features of R1 (VNF onboarding and service creation, service provisioning, closed loop, multi-VIM/Cloud, etc) should be demonstrated
• VNFs deployed by the use case should meet ONAP VNF Requirements and Guidelines
• The use case should be reproducible by any ONAP OpenLab
• Committed to R1 schedule
• Practicality

Gating Use Case for R1 Selection:

Below I have some initial items to set the foundation for our subsequent work. In addition to the list below, the use case priority list is also a good reference to align the effort between Integration Team and each use case. Currently only VoLTE has a priority list here: Use Case: VoLTE. The high priority items are what we should focus on when designing gating use cases.

- VNF/PNF selection:

       * For VNFs, are they open source?

       * For PNFs, how are they available to the labs? Do they have any special requirements for set up?

       * Do they conform to the ONAP spec? E.g., HEAT template, Yang model, REST API, NETCONF, data collection. If not, how much re-development work is needed to make them compatible to ONAP?

- Design time:

       * VNF onboarding is a required step.

       * Service design is more complicated. The basic requirement is to composite the service using VNFs/VNFCs that have been onboarded. On top of it, we need to define what kind of closed loop control artifacts need to be created, including DCAE apps, policies, and DGs. 

       * For closed loop control, we need to define the specific gating use cases. To be specific, what kind of data to collect, what kind of events to detect, and then what actions to take and by which module. 

- Service instantiate:

       * The basic requirement is to ensure that all the VMs and virtual networks are created as defined by the HEAT/TOSCA template. A key questions is do we allow any workaround that is not standard to the ONAP framework? For example, the standard workflow is to complete service design in SDC, and the output is then used by SO to perform instantiation. But in practice does VF-C need to get anything from outside in addition to from SO? Also do we need any manual operation or third party tools to instantiate the VMs and virtual networks?

       * Ideally configuration of the VNFs/PNFs should be done by SDNC/APPC/VF-C automatically. In practice do we need any manual configuration? Most likely manual configuration cannot be avoided. We need to explicitly define this.

       * How to instantiate DCAE? Ideally CLAMP will output a TOSCA blueprint template to the DCAE orchestrator. The blueprint will be used to manually deploy the required DCAE instances and start the closed loop.

- Closed loop control:

       * Closed loop control is previously discussed in service design and creation. The run time scenario is based on what was designed in SDC.

       * Basic types of closed loop control is to re-configure existing VNFs/PNFs based on certain events, it does not require resource allocation and change of topology. Typically the control involves DCAE, Policy, APPC/VF-C. This should be the target gating use case for R1. For each use case we need to define such closed loop control scenarios. We also need to define the specific trigger for the closed loop control.

       * More complicated closed loop control include scaling and failure recovery. Such controls will also require the involvement of SO, VIM, and A&AI. We need to evaluate the feasibility and then design the gating use case accordingly.

TSC Approved 3 Use Cases: