You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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,
    • compliant with ETSI NFV MANO architecture,
    • providing resource orchestration and full life cycle management and FCAPS for NS,
    • providing standard south bound interface to VNFMs,
    • providing north bound interface to SO, to take part in fulfilling the orchestraion and operation of end2end service,
    • providing interface and work with DCAE and Policy for Close Loop Automation.
  • GVNFM Component,
    • compliant with ETSI NFV MANO architecture 
    • providing full life cycle management and FCAPS for VNFs which do not require a vendor VNFM
    For a more detailed overview - https://wiki.onap.org/pages/viewpage.action?pageId=3247130

New component capabilities for Dublin, i.e. the functional enhancements

  1. Mysql DB migrates to OOM shared MariaDB Galera Cluster which can be used to meet S3P HA requirements.

    1. Update VF-C DB Helm Chart
    2. Update VF-C component to leverage new MariaDB Galera Cluster 
      1. Docker configuration update 
      2. DB script migrate 
      3. Other work 
  2. Configuration Improvement
    1. Investigate all VF-C configuration could be automatically injected through OOM.
  3. Data Persistence
    Add data persistent storage to avoid data loss due to pod restart

New or modified interfaces

Update VF-C Northbound APIs to align SOL005. 

If they are modified, are the backwards compatible?

       Yes, almost APIs required parameters has been supported by previous version，the alignment will add more optional parameter support which can comply with previous APIs.

Interface naming

       VF-C supports the following APIs:

  1.  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

  2.   Package management APIs( VNF/PNF/NS package create/upload/delete/update ....), such as 
     api/vnfpkgm/v1/vnf_packages
     api/vnfpkgm/v1/subscriptions

Reference to the interfaces

xxx

What are the system limits

No

Involved use cases, architectural capabilities or functional requirements

  1. Use case support

    1. CCVPN 
    2. vCPE
    3. vFW

  2. Functional Requirements support 

          a. Centralized Representation and Consistent ID of Cloud Regions

          b. HPA

  3. Listing of new or impacted models used by the project (for information only)

    1. VF-C will consume service/VNF DM and align with the above data model in Dublin release

  • No labels