VNF Onboarding
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
Phase
Activity Description Relation to OPNFV Projects Notes (feel free to
add yours)
VNF
development
Developer 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,
can be mapped to NSD , while to VNFDJuju bundle Juju charm
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
Onboarding VNF package import to
onboarding system
Developer (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 testing In 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 s), executing testsNFV environment
(package-referenced or in compatible s.SP-required) NFV environment
Models: VNF package support
for test-related metadata
VNF incorporation into
service design
SP 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
context
In compatible NFV environments (lab, pre-production, production), the SP
verifies functionality of the VNF as part of services
VNF import into
catalog
SP 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 upgraded Cycle back through the previous steps
Production VNF is deployed into
production
environment
The 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
requirements
The 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
need
Catalog Catalog for (VNF and NS) Dev Ops, On boarding and Production Catalog for OPNFV
Market Place
Catalog
considerations
OPEN-O & Intel have
considered this.
评论0