Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 9 Next »

ONAP ETSI Alignment Update presentation to the ETSI NFV on September 15th


Honolulu+ Priorities Discussion

Requirements

  • Onboard ETSI SOL004 compliant VNF/CNF packages (ETSI Package Management)
    • Support for extended VNFD, Helm Charts, Container Images/references, based on IFA 011
    • SOL001 VNF/CNF mapping to SDC AID DM (including Policy Aspect/VF-Module, VDU/VFC)
    • Enhance AAI Schema for CNF topologies for granting
    • Onboarding VNFD with configuration properties
  • Design ETSI SOL007 compliant Network Service Descriptor packages (ETSI Package Management)
    • SOL001 NS mapping to SDC AID DM
    • Generate SOL007 NS package to the "ETSI_PACKAGE" directory
  • Onboard ETSI SOL007 3.3.1 compliant Network Service Descriptor packages (ETSI Package Management) - stretch goal
    • SOL001 NS mapping to SDC AID DM
    • Preserve the original vendor NS package to the "ETSI_PACKAGE" directory
  • Support for Nested/Hierarchical ETSI SOL001 Network Service Descriptor - stretch goal
  • Support for ETSI SOL003 Or-Vnfm Interface from ONAP to external VNF Manager(s)
    • Enhance the SOL003 Adapter to support VNFM VNF/CNF orchestration
  • Support for ETSI SOL005 Os-Ma-nfvo interface between ONAP and NFVO
    • Support invocation of NFVO (SO NFVO, VFC, External NFVO) based on modeling thru SOL005 APIs
    • Enhance SO E2E Workflows for collecting parameters for NS requests
  • Support for ETSI Package distribution including Software and Container Images
    • Enhance ETSI Catalog Manager to push Container Images to CIR
    • Support Or-Vi for Software Image management
  • Support for ETSI NFV NFVO Orchestrator in ONAP SO
    • Support ETSI SOL005 and SOL003 APIs including subscription and notification
    • Support Dynamic BPMN Workflows (ability to deploy custom NFVO BPMN workflows and logic which SO is running)
    • OOF-based resource Granting for Instantiation and Termination
  • Support for ETSI-based Application Configuration (for VNF) - post Honolulu?
    • Design CBA and attach it to SDC CSAR for CDS-based configuration
    • Enhance SO NFVO to leverage CDS and SDNC, support VNF application configuration
    • Onboarding VNFD with configuration properties
    • Support the Modify Configuration APIs from SOL005/SOL003 Adapters
      • Note: expect VNFM supports the Modify Configuration APIs
  • Scaling and Healing support is NOT part of Honolulu



Architecture


Model-driven CNF LCM Orchestration

The following diagram depicts model-driven CNF LCM orchestration.

CNF Support Architecture

The following diagram depicts ETSI-based CNF support Architecture.


CNF Support

  • CNF Support is one of Ericsson’s highest priority work items for ONAP
    • Define a fast path to CNF support, and accomplish it across multiple releases (Honolulu+)
    • For now, leverage currently available ETSI Stage 2 specifications, without just waiting for ETSI Stage 3 (SOL)
  • Many (Ericsson, Verizon, Bell Canada, Huawei, others) believe the target is CNF, 5G Edge, etc. VNF support is a steppingstone towards that goal
  • CNF support and Cloud Native Support are closely related.
    • CNF enables Cloud Native (Microservices, Containers, Elastic scalability, On-demand deployment)
    • What other Cloud Native support?  APs: Define its scope and study architecture
    • In Honolulu, CNF scope is:
      1. CNF modeling and distribution support for microservice-based CNF and images,
      2. CNF LCM through SO, SO NFVO (or VFC) and VNFM via standard APIs (covering instantiation and Day 0 configuration based on Helm Charts)
        1. Note: VNFM support for CNF is vendor-specific
      3. OOF-based Granting only for both VNF/CNF Instantiation and Termination, not for VNF/CNF Healing or Scaling
      4. Software Images and Container Image Handlings via NFVO, ETSI Catalog Manager and CIR
      5. Collaborate with non-ETSI-based CNF support in SO; SO launches the CNF LCM path based on models (i.e., model-driven)


Configuration Support Architecture

This following diagram depicts ETSI-based Configuration support.


  • Leverage CBA design and SDC distribution (CBA + CSAR) for model-driven configuration
  • Leverage existing CDS, SDNC / MultiCloud path, or new ETSI-based configuration support thru Ve-Vnfm (SOL002)




  • No labels