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"
- ETSI NFV SOL
- 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.
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
- 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
- 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
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.
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