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

As mentioned in VNFM section of ETSI-MANO the VNF Onboarding is key to ability of Service Providers to take OPNFV beyond labs into field for trials and eventual integration with their architectures like ECOMP from AT&T and others from providers like China Mobile. Thus this is a critical piece for Operators and Vendors to collaborate on a global basis learn and try standards that work in real mission/business critical networks. Thus current work in OPNFV will bring contributions for OPNFV an upstream like Service Catalog, Instance Catalog to compile VNFs from different sources, will be key for Onboarding methods and helping generic and Vendor specific variations to address Carrier Grade features.

Analysis of VNF Onboarding support goals in OPNFV will benefit from a common understanding of the role of VNF Onboarding in the end-to-end product lifecycle for VNFs and services built from them. Below is an overview of this, with extra detail in the phase in which VNF Onboarding requires particular focus. This description is a work in progress and expected to be refined through discussions in the MANO WG, as well as with upstream communities/SDOs.

Lifecycle PhaseActivityDescriptionRelation to OPNFV ProjectsNotes (feel free to add yours)
VNF developmentDeveloper creates and packages VNF

Developers create VNF packages that conform to package and NFV environment requirements of particular service providers (SPs) or onboarding systems. Devs may use IDEs that support standardized, pre-validated VNF package artifacts such as:

  • NFVO consumes TOSCA VNFD. And in case VNFM provided with Juju, Juju bundle can be mapped to NSD , while Juju charm to VNFD
  • VNF Descriptor (VNFD) and elements such as described for Tacker,
  • Application configuration/state data model and APIs (e.g. via YANG)


Models: developer tools; VNF package and service environment requirements expression For Declarative TOSCA VNFD simple Profile
OnboardingVNF package import to onboarding systemDeveloper (or SP who obtains the package) uploads VNF to onboarding system, which performs basic package validation. The package contains or references (e.g. through models or build scripts) all artifacts needed to bring up the VNF in a specified NFV environment.

Models: VNF package import and validation

Artifacts in OPNFV

Parser: Information/data model (template/blueprint) validation

For CSAR and Modeling refer tosca-primer-v1.0-cnd01
VNF basic testingIn a compatible NFV environment, the SP verifies basic functionality of the VNF, per tests supplied/described by the developer in the package. This could include verifying test claims (signed evidence that specific tests succeeded in specific NFV environments), executing tests (package-referenced or SP-required) in compatible NFV environments.Models: VNF package support for test-related metadata 
VNF incorporation into service designSP applies the VNF to specific service blueprints, modifying the VNF package as needed, e.g. with service logic or for use with a specific application control system.Models: service model/blueprints 
VNF testing in service contextIn compatible NFV environments (lab, pre-production, production), the SP verifies  functionality of the VNF as part of services  
VNF import into catalogSP imports the VNF into a production catalog system, which further distributes the VNF as required/compatible with NFV environments of the SP.Domino: distribution of VNF/service related policies 
VNF is upgradedCycle back through the previous steps  
ProductionVNF is deployed into production environmentThe SP's NFVO/VNFM systems deploy the VNF per the requirements of the VNF/service/end-user.Models: NFVO/VNFM support for standard VNF package deployment; package attributes defining deployment reqs of VNF/service/end-user 
VNF resources are managed per VNF/service/user requirementsThe VNFM monitors the VNF and adjusts resources as needed per requirements of the VNF/service/end-user.Models: VNFM support for VNFD lifecycle hooks; package attributes defining resource management reqs of VNF/service/end-user 
VNF upgrade   
VNF migration   
VNF suspension/resumption   
VNF termination   
For all 3 above LC phase we needCatalogCatalog for (VNF and NS) Dev Ops, On boarding and ProductionCatalog for OPNFV 
Market Place Catalog considerationsOPEN-O & Intel have considered this.   



Please refer to link for OPNFV End User Advisory Board's describing user story and terminology.

Following is a user story from TMF forum that is enabling NFV Ecosystem for  VNF Procurement and Operations depicting the life cycle of a VNF..  

VNF Supplier
•Develop - [ •Design, •Develop, •Test] -

VNF Supplier/Service provider (procurement)

•Deliver - [ •Package, •Validate, •Accept and catalogue (onboard)]

Service provider (Service design)

•Deploy - [ •Combine, •Assemble, •Configure (software)]
Service provider (Service Delivery)
•Use - [ •Service design, •Configure (service), •Instantiate ]

Service provider (Service Assurance)

•Manage - [ •Monitor, •Update, •Upgrade]
Service provider (Service Decommissioning)
•Retire - [ •Migrate User]
VNF Logical Model can be described through UML.

The Vnf is a Class and has one or more Vnfc components and runs on one Virtual Contianer Vc. (Refer Dia below Basic VnfLogiclaModel)




Now all these begins with a Model of NFV and a high level VNFD as UML is described herein. We need some common agreed Model for VNF to even start on-boarding and managing it. Note ETSI NFV has started with Papyrus model from ONF we can borrow from it to drive YAML files for both TOSCA and YANG. Some simple UML mapping for Vnfd should be agreed as common baseline. This is all part of Eclipse Modeling Framework(EMF) and all in open source. In fact the Model and/or Movie project can be of great help to OPNFV realize the using ODL/ONOS the Connection Point Descriptor besides the VNFD we are describing to bridge the gap in topology modeling and orchestration. The ETSI NFV should publish its work items for 2016 sooner for us to leverage and keep synch, otherwise the gap will keep widening and fracturing the efforts.

Figure : VNFD high-level structure



To understand at high level use flowing Glossary:

ID                           Identifier

VNFD                     Virtual Network Function Descriptor

CP                         Connection Point

CPD                      Connection Point Descriptor

DSL                       Domain Specific Language

Flavor                   Specifies Vnf characteristics.

LCM                     Life Cycle Management

NIC                       Network Interface Controller

VDU                     Virtual Deployment Unit

VL                        Virtual Link

VLD                      Virtual Link Descriptor

QoS                        Quality of Service

Note: Additional user stories will be reviewed on the proposed basis above and can be revised as we try match with current and evolving  OPNFV architecture framework.

Note: Bryan Sullivan has taken up  VNF On boarding  with Cloudify  "hello world sample" and we plan to review his inputs and answer Margaret who has raised a valid question as what user stories for VNF on boarding we will be working on to figure out what architecture is needed to support it MANO stack above VIM. Telco-Case-Study.pdf

 A sample user scenario for Smart City is available in public of TMF forum and listed below for reference and discussions. (to be proposed review under NetReady & Domino)

 User Stories - Smart City NFV Ecosystem

 Other user stories are welcome to be discussed in  SPC/Polestar WG

Plus we can always help technical evaluation in MANO WG to support how we map this into OPNFV projects and/or Upstream to realize the user stories.




  • No labels


  1. What does this group suggest to do w/r to working VNF on boarding? If this group focuses on it, then in the Polestar group - we can just say it is being handled by this group. I think the most important thing is to create user stories for VNF on boarding and then figure out maybe the 'architecture' to support it. This would pull in all the pieces and identify the details of what needs to get done where.

  2. This group has taken up couple of use scenarios and based on discussions some of them are working on details and expect them to bring this to next meeting. Refer to updates on page and look forward to any user story Polestar would like to bring to help this MANO_WG. to update the OPNFV architecture. -Thanks Prakash

  3. It might be useful to use terms that apply in the OPNFV ecosystem when looking at items such as this.  I'm not sure it is clear to everyone where a "cpd" is used in the system and what software is impacted by the models described here.  This working group might be able to provide a translation function from the various acronyms and terms used here to a more common language in our community.

  4. I agree with Chris. That's pretty important. The other thing is that the WG cannot simply be a mask for sneaking things into OPNFV that aren't within an existing project's scope. So I would really recommend that rather than just making decisions and things about VNFM that you also engage and have the discussions with the project team, specifically. I'm not too up to speed on this area, but I thought we recently approved Opera for dealing with this. At least I remember the VNFM being a discussion point. I could have been day dreaming too. Very possible. 

  5. Polestar WG and EUG WG are looking to have a meeting during the ODL developers summit to flush out the user story specifics on VNF onboarding. Would you guys like to join us? We are shooting for Thursday of that week. 2 hours at least. I'll also try and join this call

  6. Several of us have conflict during the ODL summit in Seattle, both in Polestar & opnfv-mano-wg. Would rather prefer  co-ordination between Polestar & MANO WG  forthnightly basis on Thursday odd weeks, so that we can have joint meetings 1st and 3rd Thursdays to exchange what each of one can focus on. Once things settle we will ourselves find an amicable resolution to division of labor. We can start this with 15th September and you can then have one 29th at ODL. May be we can ask Dr. Anthony Sung from Polestar to plan a Joint call on September 15th and send us all invite, meanwhile we plan to agree on an Agenda.

  7. Appreciate the loose co-ordination through wiki link for now and will evolve as we get more active. - thanks to SPC/Polestar WG. and associated SDO's plus team members.