Skip to end of metadata
Go to start of metadata

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

Compare with Current View Version History

« Previous Version 56 Next »

El Alto

The Overall release planning is here: Release Planning#El-AltoRelease . According to this plan there is no feature change planned for El Alto.

Frankfurt

Goal for this version is disaggregation of SDN-R into three major parts.

  1. UXWeb - Web service
  2. Devicemanager - Device controlling
  3. WTDB - Database

SDN-R Disaggregation

  • Better split regarding performance from the three originations: 1. devices southbound 2. Web users northbound 3. database processing.
  • Have one entrypoint for Web User access to different web services of SDN-R: UX Web Service, REST, RESTCONF, Netconf device related
  • Use ONAP database components
  • SDNC/CCSDK/SDNR Devicemanager cluster/Netconf
    • Provide function to support NETCONF/devicehandling by devicemanagers for one OpenDaylight mountpoint in a cluster.
    • Provider to consuming microservices to publish mountpoint state changes and capabilites of NETCONF/device.  (Used by O-RAN-SC OAM) (model-driven DMaaP Agent)
  • Solution integration test covers O-RAN-SC OAM (Operations and Maintenance) Scenarios.
  • RPC/bundle for devicemanager configuration service
  • API-Gateway is entry point for all SDNR WEB service.

WEB Client

  • Data table access via extended odlux db api. See ODLUX DB API
  • configApp support Core model 1.4
  • connectApp accept IPV6 and DNS names
  • NEW aai App

Architecture

  • Three node types for wt service: Web service cluster, Devicemanager cluster, DB cluster
  • Features are provided by CCSDK/features/sdnr. 
  • One SDN-C/SDN-R image. Node types are configured:
    • by configuration parameter: WTSDNR-WEB, WTSDNR-DEVICEMANAGER, WTSDNR-DB
    • El Alto configuration "WTSDNR" not supported anymore
  • Server platform (Bold new in Frankfurt):
    • WEB: SDNC/ODL/Karaf: apigateway, odlux, helpserver, dataprovider
    • DEVICEMANAGER SDNC/ODL/Karaf: devicemodel, devicemanager, websocketmanager2 (Discussion: dataprovider as devicemanager DB client service)
    • DB: Alpine + Elasticsearch (ODL/Karaf not nessecary) .. Existing ONAP ES Image if possible.
  • APIGateway: Add RestConf Forwarding
  • DB as a Service
  • WS notification forwarding to WEB Service and Client
  • Devicemanager disaggregation for multi-technolgy support. (Used for CoreModel 1.4)
    • Goal: Different devicemanager bundles, managing netconf devices. E.g. devicemanager1.2, devicemanager1.4, DevicemanagerPM. 
    • See SDNC-848
    • Selection depends on capabilites provided by hello-answer

    • Create Mountpoint Status Provider: model-driven DMaaP Agent  

WEB Cluster-DevicemanagerCluster - DB Cluster setup for dev environment and kubernetes

  • Each cluster is providing a Kubernetes services
  • Service access via DNS Name

Tasks

Epic 1 SDN-R disaggregation
Story 1 Define disaggregated architecture
Story 2 Dataprovider
         Task1 Provide own bundle and specify northbound interface.
         Task2 Provide test-solution for ODLUX Development
         Task3 Integrate with WT-Common

 Story 3 Extend other components to new architecture
Story 4 DBaaS awareness
Story 5 WS Notification Handling through webServices
Story 6 multi-technology support for devicemanager
Story 7 Support CoreModel 1.4
Story 8 OOM solution of clustered disaggregated SDN-R
Story 9 Adjustment of UX clients to new dataprovider
Story 10 Solution Integration
Story 11 Security considerations, Vulnerability report
Story 12 Create WT-Common bundle for Configuration

Epic 2 Network technology evolution and Integration
Story 1 support IPV6
Story 2 TLS/https everywhere
Story 3 ONAP Portal integration
Story 4 ONAP authentication/authorization

Epic 3 Model-driven DMaap agent
Story 1 Define architecture/API
Story 2 enhance device manager

Epic 4 UX Evolution
Story 1 ODLUX AAI App
Story 2 Complete Configuration app (Prio 1)
Story 3 User/Group management App

Open points

  • Cluster internal notification handling
  • Configuration 
    • Which configuration for which cluster 
    • How many configuraton files
    • Run-time reconfiguration only via RPC
    • Internal cluster synchronization to be specified.
    • Initial configuration via file
    • Using MDSAL

References



  • No labels