(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
  • No labels