Page Status:
...
Updated by PTL on
Component Status:
...
Updated by PTL on
Last Reviewed on:
Certified by:
1. High Level Component Definition and Architectural Relationships
SDN-C / App-C:
| draw.io Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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.
...
- Configure Network Functions (VNF/PNF)
- Provides programmable network application management platform:
- Behavior patterns programmed via models and policies
- Standards based models &protocols for multi-vendor implementation
- Extensible SB adapters such as Netconf, Ansible, Rest API, etc.
- Operational control, version management, software updates, etc.
- Local source of truth
- Manages inventory within its scope
- Manages and stores state of NFs
- Supports Configuration Audits
2. SDN-C/APP-C API definitions
Controller provides the following interfaces:
| Interface Name | Interface Definition | Interface Capabilities | API Spec (Swagger) |
|---|---|---|---|
| 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:
...
| 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 |
3. Component Description:
4. known system limitations
- Lack of clarity & roles in the controller (which controller does what?)
- Proliferation of controller instances (many similar yet different controller instances)
- Divergence of controller implementation (lack of common controller framework)
- Duplicate and uncoordinated interfaces (lack of uniform common services in southbound interfaces)
- Controller resiliency and horizontal scaling
5. Used Models
Controllers use the following models:
- TOSCA
- YANG
6. System Deployment Architecture
Controller consists of the following containers:
...
draw.io Diagram border true viewerToolbar true fitWindow false diagramName xxxx Deployment View simpleViewer false diagramWidth 1291 revision 1
7. New Release Capabilities
- Upgrade of ODL to Sodium (SR3 initially - SR4 when available in late August)Aluminum SR (Service Release) 2
- Upgrade to Java 11
- OpenDaylight separation:
- Currently, CCSDK/SDNC/APPC is installed as a set of OSGi features within the OpenDaylight karaf container. This means that each ONAP release is tightly coupled with a specific OpenDaylight release. In order to loosen this coupling - so that ONAP deployers can use the same ONAP release with whatever OpenDaylight release suits their needs - CCSDK/SDNC/APP will move towards a microservice-based architecture, where components are installed as springboot-based containers.
- / Python 3.
- This was mostly completed in Guilin, but some cleanup is needed
- Removal of Java 8 / Python 2 executables
- Upgrade to Python 3.9
- This was mostly completed in Guilin, but some cleanup is needed
- OpenDaylight separation:
- In Honolulu release, SDNC will have 2 implementations of its generic resource API:
- The current ODL-based implementation
- A new springboot-based implementation
- We plan to test both versions to validate completeness of the springboot-based implementation. If successful, we would deprecate the ODL based version in Istanbul and remove it in Jakarta.
- In Honolulu release, SDNC will have 2 implementations of its generic resource API:
- Note: RunTime Config DB in CCSDK has been replaced by the standalone project CPSRunTime Config DB is an independent component that is integrated with the ODL SDN-C controller in R7 (Guilin release). The RunTime Config DB capabilities are part of CC-SDK. q.v. CONFIGURATION & PERSISTENCY SERVICE R6 for more information.
8. References
- APP-C overview & User Guide: https://docs.onap.org/en/casablanca/guides/onap-developer/developing/index.html#application-controller
- SDN-C overview & User Guide: https://docs.onap.org/en/casablanca/guides/onap-developer/developing/index.html#software-defined-network-controller
...