Last Reviewed on:
Certified by: Dan Timoney
Note: ONAP has two application level configuration and lifecycle management modules called SDN-C and App-C. Both provide similar services (application level configuration using NetConf, Chef, Ansible, RestConf, etc.) and life cycle management functions (e.g. Stop, resume, health check, etc.). They share common code from CCSDK repo. However, there are some differences between these two modules (SDN-C uses CDS only for onboarding and configuration / LCM flow design, whereas App-C uses CDT for the LCM functions for self service to provide artifacts storing in APP-C Database). SDN-C has been used mainly for Layer1-3 network elements and App-C is being used for Layer4-7 network functions. This is a very loose distinction and we expect that over time we will get better alignment and have common repository for controller code supporting application level configuration and lifecycle management of all network elements (physical or virtual, layer 1-7). Because of these overlaps, we have documented SDN-C and App-C together.
Controller provides the following interfaces:
| Interface Name | Interface Definition | Interface Capabilities | API Spec (Swagger) |
|---|---|---|---|
| ORAN-Policy | A1 policy management updates | An interface to accept policy management updates for distribution to managed non-RT RICs | A1 Policy Management API (yaml) |
| CONE-1 | Operations Interface APP-C : LCM | An interface to request for Lifecycle management operations on network resources. This is the same interface as CONE-2, but is invoked by a command line tool (e.g. curl) instead of by a system. | No Swagger, but documented in ReadTheDocs |
| CONE-2 | OSS Interface APP-C : LCM | An interface to request for Lifecycle management operations on network resources | No Swagger, but documented in ReadTheDocs |
| CONE-3 | Service Order Interface (GENERIC-RESOURCE-API) | An interface to request for Configuration and Lifecycle management operations on network resources | GENERIC-RESOURCE-API swagger (yaml) |
| CONE-4 | Policy Interface SDN-C: LCM | An interface to support LCM requests such as Restart, Rebuild, Migrate, Evacuate operations on network resources (APP-C interfaces with openstack to send those LCM requests to VNF/VNF-C/VM) | Swagger TBD - Interface format is the same as APP-C LCM (see ReadTheDocs) |
The current API documents can be found at:
https://onap.readthedocs.io/en/casablanca/submodules/appc.git/docs/index.html
Controller consumes the following interfaces:
| Interface Name | Interface Definition | Interface Capabilities | API Spec (Swagger) |
|---|---|---|---|
| CONE-5 | Rest API | An interface for communication with external systems such as IP management | |
| CONE-6 | Resource Chef API | An interface for configuration and Lifecycle management of network resources using Chef protocol | |
| CONE-7 | Resource NetConf API | An interface for configuration and Lifecycle management of network resources using NetConf protocol | |
| CONE-8 | Resource Ansible API | An interface for configuration and Lifecycle management of network resources using Ansible protocol | |
| SDCE-6 | SDC Interface | An interface to receive resource Templates from SDC design catalog | |
| CDSE-1 | CDS Interface | An interface to receive resource blueprint from CDS | |
| AAIE-1 | Inventory Service Interface | An interface to create, update, query, and delete resource information and relationships | |
| POE-2a | PDP Query API | Policy Decision Point query for IP address |
Controllers use the following models:
Controller consists of the following containers:
For Istanbul, we plan to provide 2 implementations of GENERIC-RESOURCE-API:
We eventually would like to replace the current implementation with the springboot-based implementation, and run OpenDaylight as a separate pod. However, there is still some work required to close feature gaps in the springboot-based implementation before we can do so without breaking existing functionality.
In Istanbul, we plan to conduct a proof of concept of the work done to date. For this proof of concept, we will replace the SDNC controller in our local kubernetes test environment with the springboot-based version and run the standard OOM gating test suite to determine whether that the implementation to date is fully backwards compatible. Any issues identified will be tracked in Jira so that we can plan to close any gaps discovered so that we can plan to introduce our springboot-based platform as the default SDNC implementation in Jakarta.