SDN-R Frankfurt

Owned by Herbert Eiselt
Last updated: Feb 26, 2020
2 min read



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.

  • 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:

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

key summary type created updated due assignee reporter priority status resolution
Refresh

Stories

epic link key summary status
Refresh

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...?)