Versions Compared

Old Version 13

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)


Note: The ONAP Streamlining - The Process has been approved by ONAP TSC


ONAP Benefits to the Industry

Contribution - Great Accomplishments!

...

ONAP Deployment Dependencies (by Andreas Geissler)

See ONAP deployment dependenciesevolution 


ONAP Helm Charts Dependencies (by Andreas Geissler)

...

  • 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

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

Image Removed

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.

Additional analysis will be provided as needed. 

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.onap.org/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

Image Removed

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 - TBD...

Assuming that we keep coordinated "by ONAP" releases even when the platform has been discontinued

Provide each component release flexibility and evolution

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


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


Modeling Service Provider Interface

  • etsicatalogAPIE-1: Catalog API
  • etsicatalogAPIE-2: NSD Management API
  • etsicatalogAPIE-3: VNF Management API
  • etsicatalogAPIE-4: Parser API



DMaaP Service Provider Interface

  • 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

  • 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

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

Image Added


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://wiki.onap.org/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

Image Added


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


Image Added


Documentation Versioning Proposal


Image 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