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


VNF Manager is at middle layer and most important for Middle-box Appliance Vendors. Service providers need this to compose and decompose and dis-aggregate functions while still continuing to use legacy middle boxes to reach its End of Life. Thus it will be fine for standards as well Open Source offerings of VNF to evolve with different VNFM, before vendors can build better offers. Current thinking  is, it would be good for MANO stacks offered by several upstream including OPEN-O, OSM, Tacker, JuJu etc. to sort out how both VNFM and NFVO interact to support Or-Vi and V-VNfm interfaces and associated functionality and APIs to minimize gaps. Some of the OPNFV projects like Modeling, VES , Domino, SFC, VNFFG , Doctor are potential candidates who can help build the ecosystem through commonly agreed way to manage  VNF starting formats, packaging, on-boarding  to meet standards VNF life cycle management.  Eventually apply those best practices  in current use case executions like L3VPN, SFC, IPv6 and future like dis-aggregated network functions at the  edge , core and mobile IMS etc.  Service Providers acceptance of OPNFV efforts to provide inter-operability of VNF, will  be key to success and is a continuously evolving process.

Thus this will deal with Interfaces 4,5,6 and associated APIs besides VNF FCAPS,REL events and telemetry aspects.

Targets?Virtualized applications & network functions Life Cycle Management
Business Goal? VNF/VNFD On boarding, VNF Instance LC /Resource management.
Typical Scenarios?
VNF Deployment/On-boarding/Scaling/Fault-recovery using VIM & supporting NFVO
  • No labels