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

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

More detailed information under SDN-R Release/SDN-R Release Frankfurt

A further goal is the the enable SDN-R to be used and extended by O-RAN-SC.

• model-driven DMaaP Agent
• Extend SDN-R for O-RAN specific YANG-Specs and devicemanagers.

SDN-R Disaggregation means

• 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
• SDNR WEB service  is entry point for WEB Browser/Client

Used from CCSDK

• IP V6 .. Web and Server side (Actually moved to Guilin)
• Java 11 (Actually moved to Guilin)
• Use new "Databroker" MDSAL interface

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.
    • Elasticsearch Version 6.4.3 
    • (docker run -d --name sdnrdb -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" --network yaml_default docker.elastic.co/elasticsearch/elasticsearch:6.4.3)
• 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  

    • Provide Notifications via DMaaP

More detailed information: Disaggregated Architecture

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

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

Jira epics and stories

Epics

Stories

Discussion

Epics/ Stories

• 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
• Change to to new RESTCONF (Frankfuert/ G...?)