(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

Browser not supported