/
Release A: A1 Controller - Implementation Options

Release A: A1 Controller - Implementation Options

Apr 26, 2021

(NOTE: This discussion is targeted toward Release A and Release B time-frames)

There are a number of options for how we could implement an A1 controller function for NONRTRIC.

To implement an A1 controller function in an NONRTRIC based on ONAP the 2 main options for comparison here are: A) CCSDK/SDNC-based controller, or B) a CDS-based controller.

The controller function should implement the REST-based A1 interface southbound toward the near-RealTime-RIC, and should have a REST-based and DMaaP-based interface northbound.

Option A - An A1 Controller function based on CCSDK/SDNC

Components required

  • To be developed and maintained in OSC:

    • RESTCONF A1 mediation interface defined in YANG (interface subject to change)

  • To be developed and maintained in ONAP:

    • ODL-based provider function to intercept RESTCONF operations and redirect them toward the A1 REST Adapter

    • OSGI-based DMaaP Adapter (?), which may also require an SLI DG to map towards the A1 REST Adapter

    • OSGI-based A1 REST Client that (initially) implements parts of the Policy Management function defined for the A1 interface

Advantages

  • Relatively easy to implement an initial version.

  • Proven stability and maturity in SDNC platform.

  • Options to extend A1 mediation logic without additional coding using SLI DG definitions

Disadvantages

  • Any change to the the northbound- or southbound-interface the  requires a full re-compile and re-release of the bundles.

  • Code would be homed in the ONAP CCSDK/SDNC project gerrit/repo - so changes would need to be integrated across 2 separate projects (CCSDK & NONRTRIC) in separate programs (ONAP & OSC)

  • Significant coordination challenges wrt. upstreaming code, integration, testing, release cadences, requirements gathering/approval, etc

Option B - An A1 Controller function based on CDS

Components required

  • To be developed and maintained in ONAP:

    • Generic Self-Service-API ↔ DMaaP adapter

  • To be developed and maintained in OSC:

    • A1 Controller Blueprint

      • Self-Service-API definition for A1-mediation northbound interface

      • Information model for SS-API message elements

      • A1 Interface model for southbound REST client

      • Logic to map SS-API operations to A1 messages

Advantages

  • Much of the platform functionality already exists in ONAP El-Alto - except the SS-API DMaaP Adapter

  • Entirely model-driven - Requires no code change or impact in ONAP

  • Proprietary/advanced mediation logic can be embedded in the blueprint

  • No inter-platform development/integration challenges - clean decoupling / separation of concerns 

Disadvantages

  • Does not align with OSC NONRTRIC Release A plans - existing early work would be deprecated

  • Flexible/Easily-evolving SS-API NBI may require evolution in clients using the controller (e.g. payload information models)

  • CDS platform is still evolving/maturing

  • SS-API DMaaP Adapter development needs prioritization in ONAP Frankfurt backlog.

  • SS-API puts some requirements on message formats (e.g. required "headers" in messages)

Decision

Release A - Option A

Release B+ - Option B (TBC)

  • Option A solution will be in Release A deprecated