Skip to end of metadata
Go to start of metadata

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

Compare with Current View Version History

« Previous Version 3 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,
  • GVNFM Component

    There is no scope and architecture changes for VF-C in Dublin release.      For a more detailed overview - https://wiki.onap.org/pages/viewpage.action?pageId=3247130

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

      

 Functional enhancements

      1. VF-C enhancement and new  features:

      2. Python upgrade from python2 to python3

      3. JDK upgrade evaluate and migrate (Depend on the commit resource)

      4. VF-C integrate with CLI to improve VF-C Usability

      5. Improve GVNFM Driver as SOL003 adapter

      6. Provide python-based Dmaap library

      7. Supporting LCM Operation rollback(Stretch goal)

      8. Add VF-C related use case vCPE on daily CI chains 


 Platform enhancements

    1. Improving platform maturity : Mariadb-Galera DB Consolidation ,security (i.e., S3P items)

    2. Supporting use cases identified by ONAP and integration:  vCPE

    3. Supporting Functional Requirements identified:

       ETSI Alignment ： migrate VF-C catalog to modeling etsicatalog

       E2E Network Slicing: (supporting NSSMF,Stretch goal depend on the commit resource )

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

VF-C R4 API Swagger yaml

What are the system limits

Now the component Redundancy and scaling depends on Kubernetes.

Involved use cases, architectural capabilities or functional requirements

  1. Use case support

        Use Case: Residential Broadband vCPE (Approved)

  2. Functional Requirements support 

      a. VF-C will include the necessary sub-components supporting the primary objectives: meeting platform maturity goals and supporting the use cases.

      b. LCM(instantiate/terminate/heal/scaling) for NS and Vendor VNFs

            c. FCAPS for vendor VNFs

            d. LCM(instantiate/terminate) for open source VNFs

            e. Minimum VF-C components supporting above functionalities:

            f. NSLCM/GVNFM/Workflow/Vimproxy/EMS driver/vendor VNFM driver

Platform Maturity Targets

  • CII Badge silver is the stretch goal (lack resource)
  • 55% code coverage, all repos have already passed 

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

    Support for service/VNF DM and align with the above data model proposed by the modelling subcommittee in Dublin release

  • No labels