Versions Compared

Old Version 2

changes.mady.by.user Yan Yang

Saved on

compared with

New Version Current

changes.mady.by.user Yan Yang

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Project Overview

AAF is first-order Security Infrastructure being used for the following:

     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
  • AAF allows each ONAP Component to have a "Namespace" to set up their important Security Authentication and Authorization elements
    • Permissions
    • Roles
    • Credentials
  • AAF provides Access to Organizational Identities
    • There is a maintained set of Identities for use in ONAP Test Systems for each ONAP Component
  • Credentials for this Identities
    • Passwords as appropriate
      • AAF has ability to Delegate to Organization, but houses all Passwords For ONAP Testing.
    • Certificates
      • These certificates have unique Authorized Identity embedded, which supports 2 way TLS Authentication
      • These certificates can also be used as Server side certificates
  • Authorizations (Fine Grained)
    • AAF provides Applications or other Enforcement Points with APP configured Permissions
  • Roles
    • AAF provides Roles for Identities that include any Granted Permissions
  • OAuth Tokens and Introspection
    • Currently unused by ONAP
  • Locator
    • AAF Components and ports can be found Globally
    • AAF Team would like Arch Team to know the following about the Locator
      1. "Locator" is not technically restricted to AAF.  It can register (protected by Authentication/Authorization) any running process/port/interface 
      2. Registrations include Global Coordinates, allowing Clients to pick the "closest" one
      3. Locator is independent of any "Cluster" or "Container" mechanisms, which gives accessibility to any network accessible component
        1. Globally - Components can reside anywhere in the world
        2. Scalable - You can start any new instances anywhere and instantly increase capacity and usage
          1. "For best results", use Cassandra in Scalable way.
        3. Resilient - VMs, Clusters, Datacenters, K8s could go down, and Authentication/Authorization is still accessible.
  • Security FS
    • AAF provides a globally accessible Fileserver to get public security information ex:
      • RCLs
      • Root Certificates (any the Organization wants to publish)
      • Organizational approved Truststores, etc
  • Approval Processing mechanisms
  • AAF provides real-time RESTful based 
    • fast evaluation of Security Authorization (and Authentication, if housed in AAF)
    • Management API for all AAF components, protected by Stringent Authentication and Authorization
  • AAF provides Java Client Infrastructure
    • CADI Framework, primarily Java
      • Includes all AAF interactions
      • Is able to process MULTIPLE kinds of Authentication in the same Client (X509, BasicAuth and OAuth included, Adapter Interfaces for Company based elements)
    • Shiro Adapter included for ONAP use of ODL
  • AAF provides Auto-Configuration for Clients, and Auto-Generation of ONAP Certs
    • as part of "Bare Metal"
    • on Docker "volumes"
  • ROOT CA Acess
  • For ONAP, AAF is proving "Root CA Capabilities" by Using AAF Certman to generate Certs from Issuer CA.  This is for TEST only
    • AAF has the ability to use an "SCEP" protocol to CAs (example CA, Windows Server).  However, this is not provided or validated by ONAP.

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

...

  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.

New or modified interfaces

...

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

...

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.

Involved use cases, architectural capabilities or functional requirements

enhancements

      

 Functional enhancements

  1. OOF Integration Optimization
    Optimize the methodology for VNF(vdu) placement, add the process for placement with selected candidates(VIM)
  2. SOL005 Interface alignment
    a. existing APIs alignment
    b. add the APIs which supported in SOL005, such as package subscription and notification
  3. Upgrade Mutlicloud API invocation to support Centralized Representation and Consistent Identification of Cloud Region functional requirement


 Platform 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

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

    1. CCVPN Use Case (Dublin)
    2. Use Case: Residential Broadband vCPE (Approved)
    3. Use Case: vFW/vDNS (Approved)

  2. Functional Requirements support 

      a. Centralized Representation and Consistent Identification of Cloud Regions In ONAP

      b. Hardware Platform Enablement In ONAP

Platform Maturity Targets

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

...

Working "Container" modification requirements

...

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