Project Overview
VF-C leverages ETSI NFV MANO architecture and information model as a reference, and implements full life cycle management and FCAPS of VNF and NS.
- support NS and VNF lifecycle management based on the ONAP tosca data model and workflow
- support integration with multi VNFMs via drivers, which include vendors VNFM and generic VNFM
- support integration with multi VNFs via generic VNFM, which does not provide VNFM function
- support integration with multi VIMS via Multi-VIM, which include the opensource and commercial VIMs
- support microservice architecture and model driven orchestration and management
VF-C has two main components: - NFV-O Component,
- GVNFM Component
For more component description - ARC VFC Component Description – Honolulu-R8
New component capabilities for Guilin, i.e. the functional enhancements
There are no planned enhancement features for Honolulu, only minor bug fix.
VFC will support TSC must have items and continue to improve platform maturity: enhance scalability, manageability, security.
New or modified interfaces
None
If they are modified, are the backwards compatible?
None
Interface naming
VF-C supports the following APIs:
- NSLCM APIs (Create/Instantiate/terminate/delete/scale/heal....), such as
api/nslcm/v1/ns
api/nslcm/v1/ns/(?P<ns_instance_id>[0-9a-zA-Z_-]+)/instantiate
api/nslcm/v1/subscriptions
api/nslcm/v1/ns_lcm_op_occs
Reference to the interfaces
What are the system limits
Now the component Redundancy and scaling depends on Kubernetes.
Involved use cases, architectural capabilities or functional requirements
No new use case support planned for Honolulu release.
VFC has been used in Use case: VCPE and requirement: OVP in Guilin release.
Listing of new or impacted models used by the project (for information only)
None