(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