Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Members

NOTE - In order to make fast progress, we are looking to keep the group size to a minimum and consisting as much as possible of TOSCA SME's.

Kickoff Materials

Meeting Information



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 and SDO compatibility strategy.
    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


Personas & NS/NF Template Lifecycle (Draft)

Gliffy
bordertrue
nameNetwork Service And Function Lifecycle (Simplified)
pagePin7


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)



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: It may be a vendor or a service provider developer . The developer initializes artifacts/templates and descriptor according to a specific environment 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. cloud environment). It can update the values of attributes in the NS/NF descriptor.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.

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


The role of the actors is more specific per 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...

Attachments