VF-C R4 Architecture Review

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. 1. AAF Locator can now differentiate Public FQDNs from K8S FQDNs

      1. When Clients declare their Container NS, they get the Internal K8S FQDN
      2. Public FQDNs are simultaneously accessible for
         1. GUIs/Management outside Cluster
         2. Non-ONAP entities (typical usage of AAF is use by large organizations... They don't house everything in one K8S.
         3. Other Clusters (if so desired)
   2. AAF is providing more documentation and enhanced configuration helps for ONAP Components
      1. Example: Providing example "Helm" init containers to setup Volumes
   3. AAF is refactoring existing maintenance processes online for Open Source (meaning non company specific), including
      1. Analysis of expiring Creds and Roles
      2. Generation of Approval records
      3. Notification of Approvals, Creds and Roles in an external company configurable way.

2. New or modified interfaces

   1. None
      
      

3. Interface naming

   AAF Interfaces are 
      1) RESTful

      2) Relate to AAF Structures (i.e. Perm, Role, etc)

      NOTE: Because AAF is critical Infrastructure, AAF can FULLY support MORE THAN Interface version at runtime. (example, 2.0, 2.1, etc)

      3) Most AAF Access is done by supplied "CADI Framework", because it already provides

           a) Required Caching

           b) Authentication/Authorization requirements.

   Note: AAF currently supports "SCEP" Protocol to an External CA.

   Reference to the interfaces

   1. AAF's is documented primarily in the AAF GUI, protected by Authentication (with the intention of Consistent Organizational Usage... API where you need to use it)

           https://aaf-onap-test.osaaf.org:8200/gui/api
      

      Note: You need "Winriver" access to get to this system, but any running AAF System will have the same info

4. What are the system limits

   1. When configured as originally designed (on VMs), recent analysis shows

      1. Currently observing 9,000,000 trans a day on the Service (note, CADI Caching means AAF is used many, many times that, up to 100-200x s)
      2.  Top limit of 6,000,000,000 trans a day on 15 VMs.
   2. It is questionable that any K8S cluster could handle this kind of load.

5. Involved use cases, architectural capabilities or functional requirements

   1. Working "Container" modification requirements

   2. Junits
   3. Helping Clients utilize AAF capabilities

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

   1. None.