Versions Compared

Old Version 3

changes.mady.by.user Byung-Woo Jun

Saved on

compared with

New Version Current

changes.mady.by.user Byung-Woo Jun

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

Key Contacts - Byung-Woo Jun  (Ericsson)

...

Contribution - Great Accomplishments!

  • ONAP as a platform has shown e2e network automation to the industry.

  • Operators, vendors and enterprises have learned how service/network automation (modeling, orchestration, policy-based closed loop, optimization…) works on VM and Cloud-Native environments for VNF, PNF, CNF, NS, Network/RAN Slicing and e2e service thru ONAP.

  • Now, the operators, vendors and enterprises want to select and apply ONAP functions to their portfolio. No one needs to take ONAP as a whole.

  • In ONAP, there are numerous valuable use cases, that leverage and coordinate clusters of ONAP component functions (e.g., SDC, SO, A&AI, DCAE, Policy, SDNC, SDNR, CPS, CDS…) to achieve objectives, such as:

    • E2E Network Slicing

    • RAN slicing

    • Closed Loop

    • ETSI-based NS & VNF orchestration

    • Helm-based CNF orchestration

    • ASD-based (including Helm) CNF orchestration

ONAP Streamlining Goals

  • Our goal is to continue to support those use cases efficiently for use in commercial production environments and portfolios.

  • We expect the industry wants to pick and choose desired ONAP component functions, swap some of the ONAP functions, and integrate those functions into their portfolios seamlessly, without bringing in a platform.

  • ONAP streamlining, which drives individual components and clusters of components guided by use cases, will enable the flexible and dynamic function adoption by the industry.

Directions

  • ONAP stakeholders are thinking about connecting ONAP, ORAN, Nephio, EMCO, and other communities for larger objectives.

    • Reuse of selected ONAP functions

    • Functional delegations

  • Under these circumstances, ONAP streamlining is more desirable.

LF Networking - Proposal (by Magnus Buhrgard)

The following diagram depicts that ONAP components are grouped under "by ONAP".Image Removed

...

ONAP Component Obstacles, Observations & Challenges

  • ONAP components are designed for ONAP-specific consumption.

    • Instead of a component being graduated, an ONAP component becomes obsolete or unmaintained if ONAP does not have use cases for it.

    • Some ONAP component-specific features tend to be ignored if they are not used by other ONAP components.

    • ONAP component functions should be used by not only ONAP but also non-ONAP.

      • Component design should be generic and extensible in a way that would enable it to be used in non-ONAP

      • If components are more generally applicable, there is the potential to gain more traction.

  • Component dependencies and couplings to other ONAP components are in an ONAP-specific way.

    • Those dependencies and couplings could be both syntactic and semantic.

    • Numerous intra-ONAP component interfaces and communications are ONAP-specific.

    • Some limited APIs standardization efforts are in place, such ETSI MANO APIs, ASD, 3GPP...

  • Making each ONAP component ‘stand-alone’ will highlight to potential users that they can take a single component, without getting involved in the whole of ONAP.

  • Deviating from standards makes integration with other systems problematic, especially for non-ONAP.

    • Aligning with standards where possible should be global requirements.

    • If there must be a deviation, that can be done in an extensible way that enables the standard-based approach

  • Component Helm charts in OOM may need to be re-written to build/deploy a component individually.

    • CI build/integration of a vendor/operator could be less compatible with ONAP one.

    • OOM is not used by some vendor/operators.

    • In some cases, a vendor maintains a completely different set of Helm charts for ONAP components.

  • Vendor/operator-specific security and logging requirements could be different. It causes integration issues. The current security based on Service-Mesh, Ingress and Keycloak should be maintained.

  • Timelines and cadence of the ONAP release are inflexible for accommodating different release strategies.

    • Cannot create a ‘Release’ in JIRA for the component releases

    • Branching strategies are not aligned with ONAP CMO (Current Mod of Operation)

    • Resulting in an artificial split in functionality between releases

What is consumable in ONAP? (by Magnus Buhrgard)

  • Individual components (run by self organizing teams).                - OK

    • The teams dictate their own processes and timelines

    • Centers of excellence

    • Flexible dialogue with users

    • Continuous development and responsive deliverables

  • Cluster of components guided by use cases.                                - OK

    • Bringing greater value than individual components

    • Useful in marketing, Proof-of-Concept

  • Platform                                                                                             - NO

    • No commercial uptake

    • No smooth upgrade

    • Sets expectations for a scope way beyond what can be expected from a “normal” open-source community

    • Based on a corporate development mindset

ONAP needs to get more agile and better at managing expectations!

ONAP Component Streamlining Target

  • Modularity & independent management

    • Stand-alone component

  • Interface abstraction & loose coupling

    • Including standardization where possible

  • Extensibility & interchangeability

  • Scalability (component addition, update and deletion without disruption) – native Cloud-based

  • Autonomous

    Autonomous self management

  • Design for general use (ONAP & non-ONAP consumers)

  • Conformance to industry security &

    logging

    logging

  • Clustering

    Clustering components by use cases

    • Selection of the best components for a particular task in systems

    • Responsive integration and delivery

    • ONAP still can provide reference automation for coordination

...

  • OOM is not a stand-alone product under "by ONAP". It is collection of scripts for component build, configuration and deployment. Also, it configures for security such as Ingress, oauth2-proxy and Istio.

ONAP

...

  • Check-in ONAP component code and triggering build processes
  • Thru the CI pipeline, each ONAP component will be built by scripts (e.g., modified OOM, or project-own scripts), along with SBOM

...

  • at OOM or ARCCOM next week…

...

  • e.g., SO, SO-NFVO, SO-CNFM…
  • In OOM, there are flags for the sub-component installation. As a result, exposed component scopes can be adjusted, as needed.

Image Removed

Image Removed

ONAP Component Individual Storage and Deployment

The following diagram depicts the CI/CD pipeline and deployment of ONAP.

Image Removed

Separation of ONAP Components

The reference OOM wiki page will describe how to separate ONAP components, (Montreal) Separation of ONAP components 

In there, the following main topics are described.

  • Helm chart separation, versioning concept and release management
  • Deployment options (ONAP centralized vs. individual components)

ONAP Deployment Dependencies (by Andreas Geissler)

See ONAP deployment evolution 

ONAP Helm Charts Dependencies (by Andreas Geissler)

See ONAP Helm chart dependencies 

Break ONAP Monolithic Version Schema (by Florian Bachmann)

See Proposal: Break ONAP's monolithic version schema

ONAP Component Autonomous and Interface Abstraction

  • ONAP component functions should be designed/used for/by not only ONAP but also non-ONAP.
  • ONAP component functions can be substituted and/or extended by vendors/operators
  • Component dependencies and couplings to other ONAP components should be removed.
    • Those dependencies and couplings could be both syntactic and semantic
    • Intra-ONAP component interfaces and communications should not be ONAP-specific.
    • Aligning with standards where possible (e.g., ETSI NFV MANO, ASD, 3GPP SA5…) should be global requirements
    • If there must be a deviation, that can be done in an extensible way that enables the standard-based approach
  • The exposed service interfaces should be for both ONAP and non-ONAP; promote ONAP component interfaces as LFN de facto standards
    • If exposed service interfaces conform to industry standards (e.g., ETSI SOL005, ETSI SOL003, 3GPP SA5), the interactions between the service provider and consumer would be simplified (e.g., VFC case in this diagram)
  • For now, the service consumers can use “adapters” which choose a desired service interface
  • e.g., AAI interfaces

Image Removed

Action Points

  • Promote ONAP component API models and interfaces, as open-source (at least LFN) de facto APIs
  • Study the following ONAP component exposed service API models and interfaces

SDC Service Provider Interfaces

  • SDCE-1: VF Designer
  • SDCE-2: Service Designer
  • SDCE-3: DCAE Designer
  • SDCE-4: Service Test
  • SDCE-5: Service Test Dist
  • SDCE-6: Artefact Distribution
  • SDCE-7: Service Catalogue Retrieval

SO Service Provider Interfaces

  • SO-E-01
  • SO-E-02

AAI Service Provider Interfaces

  • AAIE-1: Inventory Service
  • AAIE-2: AAI GUI

Policy Service Provider Interfaces

  • POE-1: Policy Type Design
  • POE-2: Policy Design
  • POE-3: Policy Management
  • POE-4: Data Ingress
  • POE-5: Decision Query
  • CLPOE-1: Control Loop LCM, Policy LCM

DCAE Service Provider Interfaces

  • DCAE-EXT1: VES Collector
  • DCAE-EXT2: HV-VES Collector
  • DCAE-EXT3: Data File Collector
  • DCAE-EXT4: SNMPTrap
  • DCAE-EXT5: RESTConf
  • DCAE-EXT9: Data Extraction Service (DES)
  • DCAE-EXT10: DCAE Openloop/CL Event
  • DCAE-EXT11: PNF Registration Handler
  • DCAE-EXT13: Slice Analysis MS
  • DCAE-EXT14: PM Subscription Handler Service

CPS Service Provider Interfaces

  • CPS-E-01: Provides remote clients with model LCM
  • CPS-E-02: Generic data mutation interface
  • CPS-E-03: Generic read/query interface
  • CPS-E-04: Change notifications
  • CPS-E-05: xNF data access
  • CPS-E-06: Temporal data access
  • CPS-E-07: Administration interface

OOF Service Provider Interfaces

  • OOFE-1: Homing / Traffic Distribution
  • OOFE-2: PCI/ANR Optimization
  • OOFE-4: Route Optimization
  • OOFE-5: OOF Model Administrator
  • OOFE-6: Network Slicing

UUI Service Provider Interfaces

  • UU-APIE-1: Operator Portal
  • UU-APIE-2: Customer Portal

VFC Service Provider Interfaces

  • VFCE-1: Portal / OSS Interface, based on ETSI SOL-005
  • VFCE-2: Service Orchestrator / Policy Interface, based on ETSI SOL-005

SO NFVO Service Provider Interfaces

  • SOL005: NS LCM interface

SO SOL003 Adapter Service Provider Interfaces

  • SOL003: VNFM LCM interface

VNFSDK Service Provider Interfaces

  • VNFSDKE-1: VNF Package Manager
  • VNFSDKE-2: Market Place GUI
  • VNFSDKE-3: Market Place
  • VNFSDKE-4: VNF Test Platform

Multi-Cloud Service Provider Interfaces

  • MCE-2: Resource LCM
  • MCE-3: N/A
  • MCE-4: Atomic Resource LCM
  • MCE-5: Placement optimization
  • MCE-6: Infra Provider Registry
  • MCE-7: CNF LCM

Holmes Service Provider Interfaces

  • HOLMESE-1: Rule Management
  • HOLMESE-2: Health check

Portal-NG Service Provider Interfaces

  • TBD

...

Streamlining Evolution Paths

ONAP was started as a Network Automation Platform. It provides rich e2e Service use cases and functions, but it was a big and complex network automation platform. 

ONAP is a collection of network automation functions, which provides individual component functions. To be adopted by the telecom/network industry, operators and venders, ONAP has worked on the following:

  • ONAP-Specific platform services have been deprecated (MSB, DMaaP, AAF, OOF) and replaced with industry de-facto mechanisms (Service Mesh, Strimzi/Kafka, Security framework, AI/ML driven optimization).

  • Interface normalization and standardization

  • Individual component certification

  • CD-based deployment

By leveraging ONAP individual core components, ONAP will be able to aggregate them for greater solutions.

Image Added

ONAP Component Individual Build

  • Leveraging the existing LF-based CI pipeline, builds ONAP components

    • Check-in ONAP component code and triggering build processes

    • Thru the CI pipeline, each ONAP component will be built by scripts (e.g., modified OOM, or project-own scripts), along with SBOM

  • Helm chart separation, versioning concept and release management

    • Currently, all the ONAP component helm charts have the same version number (e.g., 13.0.0). for a start,

  • Helm charts dependencies need to be analyzed (by Andreas Geissler), see https://lf-onap.atlassian.net/wiki/display/DW/Helm+chart+dependencies

  • Andreas and Florian (DT) plan to present the chart versioning

    • at OOM or ARCCOM next week…

  • PTLs need to determine granularities of project function exposures since a project can have multiple sub-components

    • e.g., SO, SO-NFVO, SO-CNFM…

    • In OOM, there are flags for the sub-component installation. As a result, exposed component scopes can be adjusted, as needed.

Image AddedImage Added

ONAP Component Individual Storage and Deployment

The following diagram depicts the CI/CD pipeline and deployment of ONAP.

...

Separation of ONAP Components

The reference OOM wiki page will describe how to separate ONAP components, (Montreal) Separation of ONAP components 

In there, the following main topics are described.

  • Helm chart separation, versioning concept and release management

  • Deployment options (ONAP centralized vs. individual components)

ONAP Deployment Dependencies (by Andreas Geissler)

See ONAP deployment evolution 

ONAP Helm Charts Dependencies (by Andreas Geissler)

See ONAP Helm chart dependencies 

Break ONAP Monolithic Version Schema (by Florian Bachmann)

See Proposal: Break ONAP's monolithic version schema

ONAP Component Autonomous and Interface Abstraction

  • ONAP component functions should be designed/used for/by not only ONAP but also non-ONAP.

  • ONAP component functions can be substituted and/or extended by vendors/operators

  • Component dependencies and couplings to other ONAP components should be removed.

    • Those dependencies and couplings could be both syntactic and semantic

    • Intra-ONAP component interfaces and communications should not be ONAP-specific.

    • Aligning with standards where possible (e.g., ETSI NFV MANO, ASD, 3GPP SA5…) should be global requirements

    • If there must be a deviation, that can be done in an extensible way that enables the standard-based approach

  • The exposed service interfaces should be for both ONAP and non-ONAP; promote ONAP component interfaces as LFN de facto standards

    • If exposed service interfaces conform to industry standards (e.g., ETSI SOL005, ETSI SOL003, 3GPP SA5), the interactions between the service provider and consumer would be simplified (e.g., VFC case in this diagram)

  • For now, the service consumers can use “adapters” which choose a desired service interface

  • e.g., AAI interfaces

...

Action Points

  • Promote ONAP component API models and interfaces, as open-source (at least LFN) de facto APIs

  • Study the following ONAP component exposed service API models and interfaces

Oslo Core Component Interfaces

SDC Service Provider Interfaces (ARC SDC Component Description - Oslo-R15 )

  • SDCE-1: VF Designer

  • SDCE-2: Service Designer

  • SDCE-3: DCAE Designer

  • SDCE-4: Service Test

  • SDCE-5: Service Test Dist

  • SDCE-6: Artefact Distribution

  • SDCE-7: Service Catalogue Retrieval

SO Service Provider Interfaces (see ARC Service Orchestrator Component Description - Oslo-R15 )

  • SO-E-01

  • SO-E-02

SO NFVO Service Provider Interfaces (see https://lf-onap.atlassian.net/wiki/spaces/DW/pages/16554594/ONAP+Streamlining+Evolution#SO-NFVO-Service-Provider-Interfaces )

  • SOL005: NS LCM interface

SO SOL003 Adapter Service Provider Interfaces (see ARC Service Orchestrator Component Description - Oslo-R15 )

  • SOL003: VNFM LCM interface

AAI Service Provider Interfaces (see ARC AAI Component Description - Oslo-R15 )

  • AAIE-1: Inventory Service

  • AAIE-2: AAI GUI

Policy Service Provider Interfaces (see ARC Policy Framework Component Description - Oslo-R15 )

  • POE-1: Policy Type Design

  • POE-2: Policy Design

  • POE-3: Policy Management

  • POE-4: Data Ingress

  • POE-5: Decision Query

  • CLPOE-1: Control Loop LCM, Policy LCM

DCAE Service Provider Interfaces (see ARC DCAE Component Description - Oslo-R15 )

  • DCAE-EXT1: VES Collector

  • DCAE-EXT2: HV-VES Collector

  • DCAE-EXT3: Data File Collector

  • DCAE-EXT4: SNMPTrap

  • DCAE-EXT5: RESTConf

  • DCAE-EXT9: Data Extraction Service (DES)

  • DCAE-EXT10: DCAE Openloop/CL Event

  • DCAE-EXT11: PNF Registration Handler

  • DCAE-EXT13: Slice Analysis MS

  • DCAE-EXT14: PM Subscription Handler Service

CPS Service Provider Interfaces (see ARC CPS Component Description - ARC Configuration Persistence Service (CPS) Component Description - Oslo-R15 )

  • CPS-E-01: Provides remote clients with model LCM

  • CPS-E-02: Generic data mutation interface

  • CPS-E-03: Generic read/query interface

  • CPS-E-04: Change notifications

  • CPS-E-05: xNF data access

  • CPS-E-06: Temporal data access

  • CPS-E-07: Administration interface

OOF Service Provider Interfaces (Deprecated)

  • OOFE-1: Homing / Traffic Distribution

  • OOFE-2: PCI/ANR Optimization

  • OOFE-4: Route Optimization

  • OOFE-5: OOF Model Administrator

  • OOFE-6: Network Slicing

UUI Service Provider Interfaces (see https://lf-onap.atlassian.net/wiki/spaces/DW/pages/16554594/ONAP+Streamlining+Evolution#UUI-Service-Provider-Interfaces )

  • UU-APIE-1: Operator Portal

  • UU-APIE-2: Customer Portal

VFC Service Provider Interfaces (Deprecated)

  • VFCE-1: Portal / OSS Interface, based on ETSI SOL-005

  • VFCE-2: Service Orchestrator / Policy Interface, based on ETSI SOL-005

VNFSDK Service Provider Interfaces (Deprecated)

  • VNFSDKE-1: VNF Package Manager

  • VNFSDKE-2: Market Place GUI

  • VNFSDKE-3: Market Place

  • VNFSDKE-4: VNF Test Platform

Multi-Cloud Service Provider Interfaces (see https://lf-onap.atlassian.net/wiki/spaces/DW/pages/16554594/ONAP+Streamlining+Evolution#Multi-Cloud-Service-Provider-Interfaces )

  • MCE-2: Resource LCM

  • MCE-3: N/A

  • MCE-4: Atomic Resource LCM

  • MCE-5: Placement optimization

  • MCE-6: Infra Provider Registry

  • MCE-7: CNF LCM

Holmes Service Provider Interfaces (Deprecated)

  • HOLMESE-1: Rule Management

  • HOLMESE-2: Health check

Portal-NG Service Provider Interfaces (see ARC Portal-NG Component Description - Oslo-R15 )

  • PortalE-1: Portal Admin Interface

  • PortalE-2: Application Admin Interface

  • PortalE-3: External App Interface

  • PortalE-4: Role Approval Interface

  • PortalE-5: Session Communication Interface

  • PortalE-6: Shared Context Interface

  • PortalE-7: Ticket Event Interface

  • PortalE-8: Web Analytics Interface

  • PortalE-9: External Request Interface

  • PortalE-10: External Access Role Interface

Modeling Service Provider Interface (Deprecated)

  • etsicatalogAPIE-1: Catalog API

  • etsicatalogAPIE-2: NSD Management API

  • etsicatalogAPIE-3: VNF Management API

  • etsicatalogAPIE-4: Parser API

DMaaP Service Provider Interface (Deprecated)

  • DMaaP-1: DMaaP Bus Controller

  • DMaaP-2: DMaaP Message Router Source 

  • DMaaP-3: DMaaP Message Router Consuming Interface

  • DMaaP-4: DMaaP Data Routing Source

  • DMaaP-5: DMaaP Data Routing Consumption Interface

SDNC Service Provider Interface (see ARC Controller Component Description – Oslo-R15 )

  • ORAN-Policy: A1 policy management updates

  • CONE-1: Operations Interface

  • CONE-3: Service Order Interface

  • CONE-4: Policy Interface

CDS Service Provider Interface

  • CDSE-1: CDS interface for Blueprint

CCSDK Service Provider Interface (it is a set of libraries for DCAE, OOM, SDNC)

  • ASDC-API: RESTConf interface for non-TOSCA

  • dataChange: RESTConf pub/sub interface

  • LCM: RESTConf for LCM events

  • SLI-API: RESTConf for service logic interpreter

  • selfservice-api: gRPC interface with CDS

  • oofpcipoc-api: RESTConf for OOF/PCI integration

CDS Service Provider Interface

  • CDSE-1: CDS interface for Blueprint

ONAP Component Runtime Security Analysis

  • ONAP components are protected by Ingress Controller, Keycloak (IdAM) and Istio (Service Mesh), with AuthN/Authz, intra-secure communications, external-secure communications.

  • ONAP components themselves do not have their own/ proprietary protection any longer (e.g., removal of HTTP Basic Authentication and HTTPs).

  • Current OOM-provided security support as described above will be provided as ONAP reference security mechanism.

  • It is assumed that vendors/operators support industry de facto security mechanism like ONAP security and imported ONAP components are protected by the security mechanism.

  • ONAP will provide documentation of security architecture, global requirements and best practices, informing how to protect/secure selected ONAP components.

    • For secure external communications, Ingress Controller, aouth2-proxy and IdAM are used

    • For intra-secure communications, Istio is be used with Cert-Manager and policies

    • For user authentication and authorization, KeyCloak is used, with SSO support and OAuth2-based token generation and validation

...

ONAP Component Code Security Analysis

...

The following lists ONAP SECCOM roles and duties:

  • Provide global requirements and best practices and audit tests - example: require secure code

  • Provide secure reference implementation and documentation - example: logging, service mesh, external security with authentication and authorization

  • Prioritize vulnerability fixes

  • prioritize secure enhancements

  • Proposal: ONAP projects work with latest version of common components such as Istio, KeyCloak, Kafka, Ingress...

ONAP Component Logging Analysis

  • ONAP supports open-source and standard-based logging.

  • ONAP already separates log generation from log collection / aggregation/persistence/visualization/analysis.

    • Each ONAP component handle log generation only thru STDOUT and STDERR, by following ONAP security logging fields – global requirements, https://

      wiki

      lf-onap.

      onap

      atlassian.

      org

      net/wiki/display/DW/Security+Logging+Fields+-+Global+Requirement

    • The log destination will be configured

    • Log collection agent(s) will be configured; ONAP reference configuration is using FluentBit as the collection agent;

      • ONAP uses a separate privileged namespace to deploy FluentBit for security reasons

      • Vendors/operators can configure it differently, based on their needs

    • Vendors/operators can realize and configure the log collection/ aggregation/persistence/visualization with their own logging ecosystem

  • There will be no/minor impact on logging due to ONAP component disaggregation

...

ONAP Component Focused Integrated Testing

  • ONAP supports

    clustering

    clustering components by use cases:

    • Selection of the best components for a particular task in systems

    • Responsive integration and delivery

    • ONAP still can provide reference automation for coordination

  • ONAP E2E integration testing can be performed for code quality.

  • Focused Integration testing can be performed, based on use cases.

  • Additional analysis will be provided as needed.

Release Management Tasks 

  • Marketing version, Montreal, will be scheduled as the previous releases.

  • Setting release schedule plans for Montreal

  • The Marketing version will be used as the Major version by ONAP projects

  • PTLs decide the minor and patch versions, based on their project release cycles and share the project versioning with TSC

    • Provide each component release flexibility and evolution

  • Integration & Pair-wise testing

  • Integration testing will continue to increase ONAP project overall qualities

  • Pair-wise testing will continue but it will be based on use cases

  • Project testing will be performed by each project team

  • For Montreal, security scanning will continue as before

  • Based on feedback during the Montreal, the release plan can be revisited

Montreal Release Plan Proposal

  • Each PTL determines their project agile cycle(s) based their features

  • PTLs/Feature owners coordinate with ARCCOM/REQCOM/SECCOM/TSC for the feature review and approval per agile iteration

  • PTLs/Feature owners may work with OOM, INT and DOC for build, testing and documentation, as needed

    • project release specific documentation should be handled in a automated fashion (e.g., scripts; PTLs create the release-specific rst and scripts put the rst contents into RTD)

  • Each agile iteration/sprint is reviewed and critiqued by the project team (and ARCCOM/REQCOM/SECCOM/INT/TSC as needed…) and is used to determine what the next step (PTL decides it) until RC

    • e.g., priorities, guidance, standards, security…

  • After Montreal, we may want to revisit the Marketing release RC and Sign off

Image RemovedImage Added

Documentation Versioning Proposal

Image RemovedImage Added

Special Interest Group (SIG) - TBD...

  • Technical coordination and governance (former TSC)

  • Architecture & Interoperability (could be on LFN level)

  • LFN security

  • LFN common practices

  • Modeling

  • LFN documentation consistency

  • Technical outreach (SDO & Open-source)

Presentation

References