Assumptions

Objectives

• Establish TOSCA as the "normative", supplier/operator neutral way to package and describe (model) network service and functions in ONAP.
• Enable template reuse and orchestration outcome consistency across ONAP related on-boarding, design, instantiation and operation activities.
• Identify TOSCA adoption barriers/gaps and recommend closure actions.

Tasks

1. Template use...
   1. Define when and how TOSCA templates are used across on-boarding, design, instantiation and operation time
   2. Define template versioning strategy.
      1. New versions of VNFDs inside VNF packages to be on-boarded
      2. Support for multiple VNF template versions (e.g.SOL001) inside ONAP (transcoding)
   3. Identify template gaps and recommend closure actions.
2. Network service and function lifecycle orchestration... 
   1. Define end-to-end component interactions and dependencies required for TOSCA based orchestration activities across on-boarding, design, instantiation and operation time.
   2. Identify interaction gaps and recommend closure actions.
   3. Define how TOSCA templates are used in conjunction with emerging encoding and packaging alternatives.
3. Recommendations...
   1. Architecture Subcommittee
   2. Modeling Subcommittee
   3. Projects

Dublin Recommendations (WIP)

• External Representation (On-Boarding) - What VNF TOSCA template flavor(s) to adopt for Dublin (e.g. SOL001 templates vs. AID templates)?
  • Continue to support SOL001 VNF TOSCA templates
    • Use v2.5.1 of SOL001 specification
• Design-Time Representation
  • Continue to support SOL001 (for pure ETSI NVF)
    • NOTE - for now, the focus is on VNFD's and PNFD's only. Will need to revisit for specification of NS's
  • Use TOSCA templates for K8S support
  • Continue to support AID (for HEAT only)
• External Representation (On-Boarding) - What VNF TOSCA template language version(s) to adopt for Dublin?
  • TOSCA Simple YAML Profile v1.2+
• Design Tools - Will SDC design tools in Dublin support creation of VNF TOSCA templates based on agreed upon flavor(s) and version(s)?
  • SDC design tools will continue to generate AID TOSCA templates for service definitions
• Orchestration Paths
  • AID - continue to use for HEAT specified VNFs, PNFs and services
  • SOL001 TOSCA  - continue to use VF-C only
  • K8S - will use SOL001 TOSCA(?) - need to double check...
• Architecture/Design Requirements for ONAP Dublin Release
  1. Support for multiple flavors/versions of TOSCA VNFD templates
  2. Support for multiple versions of TOSCA language/grammar
  3. Use v2.5.1 of SOL001 specification
  4. A "registry" approach for configurable and modifiable properties
  5. Preservation of original on-boarded template semantics and content
     
     

Personas & NS/NF Template Lifecycle (Draft)

To Do's

• Initial list of gaps - Fred (Verizon)
• Initial persona definitions - Michela (Ericsson)
• Stage definitions - Alex 
• Gaps with respect to VNF requirements  - Thinh (Nokia)
• Versions of TOSCA grammar to be supported by ONAP for on-boarding and/or internal use

Initial Gaps

1. Model for describing VNF Application Configuration Data

   1. SOL001 has VNF configurable_properties data type but no prescriptive definition of use

   2. Currently being used for setting VNF Day 0/1 configuration, e.g. self IP, NTP server, DNS server, EMS IP, …

2. VNF KPI/Indicators are not well described

   1. Need description of KPIs/indicators exposed by the VNF and access method for each

   2. VES may be a possible model

3. VNF Rules (Policies)

   1. Need default policies based on above KPIs that can be used to drive various Life Cycle operations

Persona Definition

Service Provider: The entity providing a service

Consumers: The entity requiring and consuming a service

Different actors can be involved in providing a service :

Developers: . The developer may create additional artifacts/templates/blueprint to be used during the lifecycle of the service in addition to the ones provided by the vendors (e.g. create a new SO flow).

Operations: the operation team is responsible of the status changes of a service. It operates and monitor the service status.

According to ETSI SOL004, VNF package shall support a method for authenticity and integrity assurance. The VNF provider creates a zip file consisting of the CSAR file, signature and certificate files. Manifest file provides the integrity assurance of the VNF package. The VNF provider may optionally digitally sign some or all artifacts individually, in particular software images. The security aspects of the package and its contents will be covered during the onboarding phase by the operation team.  Some vendor VNF Managers use the signatures to verify that the package artifacts haven't been modified so the original package artifacts need to be passed to the VNF Manager

Designers: It is responsible to design new artifacts to be used at run time (e.g a  microservice blueprint, a service template, a clamp blueprints).

The role of the actors can be more specific per use case/stage.

Pre-onboarding

A pre-onboarding phase is not included in the NS/NF templace lifecycle above .

During the pre-onboarding phase/validation phase, TOSCA descriptor is validated according to the Validation Program based on VNF SDK tools. Today this is applicable to NF only, it could be applicable to NS too in the future. ONAP Reference: VNF Test Platform (VTP)

Use Case: VNF package validation

Actors: Vendor or Operator 

Role: They both can run the test cases/test flows Different validation tools options are provided where both a vendor or an operator as a 3rf parties lab testing can run test cases.

Onboarding

Design

Instantiation

Operation/Use

Contributions...