Page tree
Skip to end of metadata
Go to start of metadata

Minimal feature set to get started with VNF OnBoarding and Deployment


As a VNF Provider, I use the OPNFV platform to  validate a VNF Package so that  OPNFV platform returns no errors when onboarding a VNF under all of the OPNFV platform configuration options.

As a VNF Operator, I use the OPNFV platform to  validate a VNF Package so that  OPNFV platform returns no errors when onboarding a VNF under all of the OPNFV platform configuration options.

As a VNF Operator, I use the OPNFV platform to  deploy an onboarded  VNF   in accordance with  the constraints in its VNF Package so that  the deployed VNF operates successfully.

Onboarding spans from the "front door" through "deployment"

As an OPNFV end user, I want ease deployment of VNFs and VNFMs decoupling the orchestrators and NFVI / VIM.

  • Want to drive these requirements "upstream"
    • ONAP
    • Cloudify
    • OSM
  • How do we get to one framework?


As an end user, I want ease deployment of VNFs and VNFMs using my orchestrators and reproducible on my NFVI & VIM.

As an end user, I want a modular architecture with interoperable components.

Reuse these automated processes on pre-production and production environments.

Package portability and interoperability.  Possibly supporting OVFs.

OPNFV deliverables to move the industry forward

  • Drive test cases using sample VNFs
  • Move towards using the ETSI NFV SOL package specification for all VNF testing
  • Define a certification process for VNF onboarding
  • Closed loop event control
    • Edge platforms with a distributed control plane
    • VNFM
      • Scale up and scale down
      • Recover from failure
  • License management
  • Defined hardware capabilities
    • Abstraction from run time environment (desired state)
    • Introspection of platform capablites
      • Enable the VNF to maximize performance
      • Merge cloud native framework TOSCA and YANG or telecommunications frameworks
      • Drive the data model for inventory
    • Minimum hardware requirements
      • DPDK?
      • Crypto offload?
    • Create an information model the infrastructure platform (enhanced platform awareness)
      • Stronger links with ETSI NFV docs, where those documents exist
      • Agnostic to control plane OpenStack, K8 etc.
      • Document what is available today
      • Identify which drivers are needed in VM image
  • Manage crypto keys from VMs and containers.
    • Secure elements

VNF Options

This may require a number of Reference VNFs to validate all of the VNFC deployment constraints that could be expressed in the VNF Package.

The VNF Package  to be onboarded  must be retrievable as a single entity

  • Could be a tarball, zip etbc., but may be components identified in some sort of manifest.
  • Could be retrieved as delta - only the changes from previous version etc. 
  • ETSI GS NFV SOL004 defines a VNF package structure.  (Would implementing this be sufficient for the VNF packaging?)


The VNF Package to be onboarded must include all necessary metadata and binary executables to enable deployment.

The VNF Package may be a proprietary VNF, an open source VNF or a test VNF.

The VNF may have a single VNFC, or multiple VNFCs. 

The VNF must be able to detect whether it has been deployed correctly.


Actor Options

The VNF Provider and VNF Operator  are assumed to be independent commercial entities.

The  onboarding and deployment operations may be done by the  VNF Provider, the VNF Operator, the OPNFV Community. The OPNFV community may include some set of onboarding functionality as a part of one of the releases of the OPNFV Reference Platform.


VNF Onboarding Success / Failure

To succeed,  the OPNFV Reference platform must have the binaries of the VNFCs extracted from the input Package and available for deployment from image storage managed by the OPNFV Reference Platform.

To succeed the OPNFV Reference Platform must have the metadata of the VNF Package parsed and stored for association with the VNFCs when deployment is triggered.

The onboarding fails if the OPNFV Reference Platform cannot extract the binaries and metadata.

The onboarding fails if the OPNFV Reference Platform cannot parse the deployment constraints in the metadata


VNF Deployment & Operation Success / Failure

The VNF Deployment and Operation succeeds if the VNF is deployed in conformance with its VNF package metadata and is operating normally.

The VNF Deployment and Operation fails if any of the expected VNFC(s)  fail to deploy in accordance with the VNF package metadata

The VNF Deployment and Operation fails if any of the expected VNFC(s) are not active and operating normally

The VNF Deployment and Operation success,  a VNF with multiple VNFCs, the appropriate internal connectivity between those VNFCs must also be established


VNFC deployment constraints

The VNF Package metadata should identify whether the VNFC can be deployed on x86 or ARM  processor architectures.

The VNF Package metadata should identify whether the VNFC requires hardware acceleration options to be available

The VNF Package metadata should identify whether VNFCs can be deployed on the same processor or not under Affinity/ anti-affinity constraints.

Support a phased approach for VNF onboarding

Start the VNF onbarding in a lab enviroment for testing prior to moving into production.

Roll out to staging enviroment.

Move to production.

Ability to integrate and leverage processes with the VNF lifecycle.  Updates etc.

Future Feature Enhancements 

additional testing of the VNF for acceptance, characterization, security, reliability, scalability, stability, robustness, etc. 

may need to characterize types of VNFs e.g., complex vs simple, with / without dependencies,

network serice onboarding

Scope of work

Support multi tenancy to allow customers to run their services. **possibly move to another pain point

  • Provider to provider hosting
  • Customer hosting their VNFs
  • Application marketplace


  • No labels


  1. I have added from OPNFV MANO VNF Onboarding page to this for user scenario and try see how we can address technically. +1 to Bryan & SPC / Polestar WG.

  2. Should networking be included in the user story?

    1. @Margaret: VNFC connectivity establishment is identified in the success criteria for the VNF deployment.

      Are you looking for a NS deployment rather than a VNF deployment?

  3. Can you please expand what you mean by networking?


  4. i just saw connectivity between VNFCs - but also maybe among VNFs..


    1. Yes both are part of VNFD (Descriptor) and made of VNFC's (components) and implemented using VDU (deployment units) linked or connected through VL (virtual links) between CP (connection Ponits or ports). Thus even a standalone VNF will need some way to connect with network interfaces to even test for minimum pings to host and external network.

  5. IMO there needs to be decomposer of the issues here...


    Actor roles need to be ECO-System based (go big picture here)- myopic work here will need to be redone.

    Then we have stages /  steps in "on-boarding" 

    a) P2V - make it work on a vanilla platform (figure out your system requirements first)

    b) VNFD packaging - this is done on"per platform" because of different platforms, templates, and catalog approaches

    c)  NetOp's process of testing the VNFD package

    c)  Catalog injestion & version management process (aka license management)


    Anyone can say I ported my application and it's now virtualized...   but doing mass applications requires a framework that delineates what part of the process you are in.

    Not to mention we don't have a vanilla load outside the Vanilla Open Stack approach.




    1. Mike,
      My assumption is we have OPNFV VIM say Release B/C with Defined Pharos PODs and so we do have base IaaS and NFVi over which we are interested in on-boarding and deploying VNF. So safe to use Opestack network model along with associated SDN Controller as per OPNFV.

      1. I agree on the open stack vanilla approach... 


        I think we need some provider help on evolving TOSCA..

        The problem here is that we don't have a Topology that is both top down, and telecom customer focused on how to place resources.

             I can't solve that here because it requires all the telecom trading partners who use B2B API's to come up with a universal NFV access topology model that would become meta-class for TOSCA use on how to deploy VNF's.   

          I'll be starting a provider like effort to do this in the 4th Quarter at the BBF provider group.   Hopefully we can get everyone from all the different open sources to use a single topology model.. 


        but we have to create one first (smile)



    2. @Mike - the high level ecosystem role definitions (Actors)  should be on this page. It sounds like you have a commercial context (P2V?) that has some actors we need definitions for.

  6. General assumption is that the capabilities might build over time. So we might want to look for ways to identify simpler capabilities that could be implemented sooner. Looking for functionality that can be implemented across multiple build scenarios. Complete Specification conformance may not be achievable in one release - e.g. IFA 11 specification for VNF package

    one approach may be classifying VNFs  so that simpler VNFs could be implemented in an earlier release.



  7. Northbound APIs for VNF Onboarding & Deployment

    Since the OPNFV will exist as a part of a larger ecosystem, then it is important that VNF onboarding and deployment not only be accomplished by Actor manual interaction, but also via interaction with other automation systems (ex. orchestrators) outside the OPNFV via well-defined APIs & protocols. Therefore, propose that Actor Options & Success Criteria explicitly include these considerations. If there is agreement, I'll draft candidate language to be added.

  8. are we planning to use VNFD based on TOSCA?

    1. TOSCA is likely to be used in the data modeling for the cloud-related resources of VNFs. In the Models project we are developing reference VNF blueprints based upon it. But there are also models for other purposes (e.g. VNF app internal config and control) that will be most likely based upon YANG, and other artifacts of a modeled VNF (e.g. policy, analytics,...) that may be modeled in other formats.

  9. Anonymous


          All we need to do to align TOSCA (which is really just a principle in template form) is to create the Topology meta names for the Telecom environment so that the system can handle where to deploy things.

       I started project in the BBF (Top down topology for orchestration template NPIF)  bbl2016.914 is the contribution number.  The goal of this is to create a top down customer view holistic view of the network BBF (residential), MEF (Enterprise), and 3GPP (wireless).

       There is no "meta-class tree" on that...  We do have Op's tree's for network domains, and Business like SID tree's for Operator holistic views.  But CLOUD... the key cloud users is the user, not the provider, so we need a Customer portal topology view to execute this.


    Mike Bugenhagen