ONAP Streamlining Evolution
- 1 Key Contacts - @Byung-Woo Jun (Ericsson)
- 2 Note: The ONAP Streamlining - The Process has been approved by ONAP TSC
- 3 ONAP Benefits to the Industry
- 4 LF Networking - Proposal (by Magnus Buhrgard)
- 5 ONAP Component Obstacles, Observations & Challenges
- 6 What is consumable in ONAP? (by Magnus Buhrgard)
- 7 ONAP Component Streamlining Target
- 8 ONAP Streamlining Evolution Paths
- 9 ONAP Component Individual Build
- 10 ONAP Component Individual Storage and Deployment
- 11 ONAP Component Autonomous and Interface Abstraction
- 11.1 Action Points
- 11.2 Oslo Core Component Interfaces
- 11.3 SDC Service Provider Interfaces ( )
- 11.4 SO Service Provider Interfaces (see )
- 11.5 SO NFVO Service Provider Interfaces (see )
- 11.6 SO SOL003 Adapter Service Provider Interfaces (see )
- 11.7 AAI Service Provider Interfaces (see )
- 11.8 Policy Service Provider Interfaces (see )
- 11.9 DCAE Service Provider Interfaces (see )
- 11.10 CPS Service Provider Interfaces (see )
- 11.11 OOF Service Provider Interfaces (Deprecated)
- 11.12 UUI Service Provider Interfaces (see )
- 11.13 VFC Service Provider Interfaces (Deprecated)
- 11.14 VNFSDK Service Provider Interfaces (Deprecated)
- 11.15 Multi-Cloud Service Provider Interfaces (see )
- 11.16 Holmes Service Provider Interfaces (Deprecated)
- 11.17 Portal-NG Service Provider Interfaces (see )
- 11.18 Modeling Service Provider Interface (Deprecated)
- 11.19 DMaaP Service Provider Interface (Deprecated)
- 11.20 SDNC Service Provider Interface (see )
- 11.21 CCSDK Service Provider Interface (it is a set of libraries for DCAE, OOM, SDNC)
- 11.22 CDS Service Provider Interface
- 12 ONAP Component Runtime Security Analysis
- 13 ONAP Component Code Security Analysis
- 14 ONAP SECCOM Roles
- 15 ONAP Component Logging Analysis
- 16 ONAP Component Focused Integrated Testing
- 17 Release Management Tasks
- 18 Documentation Versioning Proposal
- 19 Special Interest Group (SIG) - TBD...
- 20 Presentation
- 21 References
Key Contacts - @Byung-Woo Jun (Ericsson)
Note: The ONAP Streamlining - The Process has been approved by ONAP TSC
ONAP Benefits to the Industry
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".
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 self management
Design for general use (ONAP & non-ONAP consumers)
Conformance to industry security & logging
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 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.
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,
e.g., projects with PTLs can start with 13.0.0. as the major Montreal release, and they can play with minor version(s) based on their release cycle, e.g., 13.0.1, 13.1.0… Projects without PTLs (or no improvement) will have the major Montreal version, e.g., 13.0.0
Other options: see, Break ONAP’s monolithic version schema (by Florian Bachmann), https://lf-onap.atlassian.net/wiki/display/DW/Proposal%3A+Break+ONAP%27s+monolithic+version+schema
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.
ONAP Component Individual Storage and Deployment
The following diagram depicts the CI/CD pipeline and deployment of ONAP.
Deployment options: individual components vs. ONAP centralized
See the current Helm deployment (Andreas Geissler created), https://lf-onap.atlassian.net/wiki/display/DW/ONAP+Deployment#ONAPDeployment-CurrentHelmDeployment
Instead of deploying a whole onap_release thru “helm deploy”, pick up ONAP components individually from repositories by leveraging CD
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)
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 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 https://lf-onap.atlassian.net/wiki/spaces/DW/pages/16553686 )
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 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 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
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
Each ONAP component needs to meet code security practices and certifications that are defined by SECCOM. There would be no direct impact for ONAP Streamlining; i.e., business is as usual.
Additional analysis will be provided as needed.
ONAP SECCOM Roles
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://lf-onap.atlassian.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 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
Documentation Versioning Proposal
Use of Marketing version along with minor and patch version(s): current ones
Suggestion (checking possibilities)
https//docs.onap.org/projects/onap-doc/en/montreal/index.html // for main doc page
https//docs.onap.org/projects/onap-projectname/en/x.y.z/index.html
https://docs.onap.org/projects/onap-cps/en/13.1.1/index.html // support project-specific doc versioning
https://docs.onap.org/projects/onap-cps/en/13.0.1/index.html // support project-specific doc versioning
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
ONAP Streamlining - The Process at SECCOM and ARCCOM, 2023-7-18, https://jira.onap.org/secure/attachment/18920/ONAP%20-%20Streamlining%20the%20process-2023-7-18-v2.pptx
ONAP Streamlining - The Process, presentation slide deck for TSC, 2023-8-3, ONAP - Streamlining the process Report-2023-8-3.pptx
ONAP Streamlining - The Process, presentation slide deck - v2, ONAP - Streamlining the process Report-2023-8-3-v2.pptx
ONAP Streamlining - The Process, work items, https://jira.onap.org/secure/attachment/18952/ONAPStreamliningWorkItems-2023-8-22.pptx
ONAP Streamlining - The Process, Release Plan, https://jira.onap.org/secure/attachment/18956/ONAP%20-%20Streamlining%20the%20process%20Report-2023-8-29-v3.pptx
ONAP Streamlining - The Process, Release Plan for TSC approval, at https://jira.onap.org/secure/attachment/18969/ONAP%20-%20Streamlining%20the%20process%20Report-2023-9-7-v1.pptx
References
ONAP Streamlining LFN D&TF June 2023 presentation, https://wiki.lfnetworking.org/download/attachments/82906137/ONAP%20-%20Streamlining%20the%20process-v7.pdf?version=1&modificationDate=1686246324000&api=v2
ONAP Deployment dependencies (by Andreas Geissler), ONAP deployment evolution
ONAP Helm chart dependencies (by Andreas Geissler), ONAP Helm chart dependencies
Proposal Break ONAP's monolithic version schema (by Florian Bachmann), Proposal: Break ONAP's monolithic version schema