Overview
When performing Control Loop actions such as reboot, scale out, modify config, etc., the API's used by the controllers and orchestrators (eg. SO, VFC, APPC) vary in design, implementation and complexity. This creates the problem of significant software development for every API supported by the controller/orchestrator that needs to be invoked during Control Loop enforcement by the Policy Platform. In addition, any company that uses the ONAP Platform internally may have their own custom controllers/orchestrators as well as custom applications (eg. Email notification, ticketing system, Q-Chat) that the company wishes to be used during Control Loop event processing. Again, significant development will be required in the Policy Platform to support those custom API's.
The proposal is to design a simplified, reusable event-based notification messaging format that could be supported by all the applications involved in Control Loop event processing. Such a simplified messaging structure would also advance the ONAP platform towards performance gains for future Control Loops that require Control Loop Operations to perform in under X milliseconds. With a simplified messaging format, faster versions of the messaging platform could be plugged in as desired. Eg. a faster version of Dmaap, kafka, vert.x, etc. installed in an edge cloud location.
The development of the Common Event Notification messaging format would be simple, lightweight and can be shared by all the controllers, orchestrators, and custom application components. Since the controllers, orchestrators and applications already have to develop their API, all those components have to do is implement reception of the messages and either translate to their current API. Ideally, those components may be able to remove their API layers and simplify their codebase.
Business Requirement
The business requirement is to develop the Event based Common Notification messaging format for Control Loop Operations and integrate into the projects involved in Control Loop Operations. The Policy Framework will create a template to support the new format. The ONAP specific controllers and orchestrators (eg SO, APPC, VFC, SDNC) can choose to support the Event Messages either by migrating directly to support them, or mapping to their internal API.
In addition, the CLAMP project will need to know what operations and their parameters are required by the controllers/orchestrators in order to specify Control Loop actions to be taken when a Control Loop event occurs. Thus, a specification must be provided by the controller/orchestrator/application so that CLAMP can easily produce Control Loop Operational Policies for the control loop being designed. It is desired that such specifications be uploaded as an artifact into the SDC Catalog for CLAMP project to utilize to build control loop operational policies.
Goal if is to standardize the ability to build Control Loop Operations without requiring large amounts of development. The development will only be required in the controller/orchestrator/application code and not in the other projects such as Policy, CLAMP and SDC.
Benefits:
- Simplification of interaction between policy and applications.
- Re-usability - any company that ingests ONAP can easily integrate own applications into control loops
- Code Reduction - event message format code is smaller and re-usable, policy development will be smaller.
- Generalization - CLAMP can build any control loop action
- S3P Performance improvements - foresee performance improvements in simplifying the messages going back and forth during control loops.
Participating Companies
Dublin Goals
- Policy to implement the messages and flow in a Policy Operational Template
- APPC, SO, SDNC, VFC and SDNR to implement support of message and their flow from Policy
- (Stretch) CLAMP to be able to read controller/orchestrator/application specifications as an SDC artifact. As a backup plan, CLAMP could simply allow the user to manually enter the application supported events.