Page Status: Reviewed by PTL - JAN-20-2021 / Feb-5-2021
Component Status: Pending ArchCom Review
Last Reviewed on:
Certified by: ChrisC
SDC High Level Component Definition and Architectural Relationships
2. SDC Component Description:
SDC is the Centralized ONAP Design Time Platform
- SDC Provides Service Provider a seamless design time user experience
- Allow SP to configure for its design environment including user roles and design workflows
- Import generic ONAP management functions (MS, Flows, Policies) from ONAP developed software and SP’s adaptations (1) (2)
- Onboard & Design resource level network functions (VNF, PNF) (3)
- Compose Service models with resources (4)
- Design Service Provider specific Management Flows and Policies for the Resource or Service Model (5)
- SDC integrates multi design tools into one platform
- Provide ONAP development a “Pluggable framework” for easy design tools integration
- SDC Provides a common Catalog for designed objects
- Support robust catalog cataloging capabilities for storage and management of ONAP standard compliant data models
- Provide linkage & management of SP’s Test/validation process & artifacts for certification of the designed models (6)
- Distributes models to runtime for execution (7)
3 SDC Target Functional Architecture
SDC provides 3 functionally distinct layers with modular software, integrated with internal APIs
4. SDC Current Release API definitions
SDC provides the following interfaces:
Interface Name | Interface DefinitionD | API Spec (Swagger) |
---|---|---|
SDCE-1 | VNF is on-boarded thru VNF Onboarding GUI | |
SDCI-1 | VNF is stored in Design CatalogVNF is stored in Design Catalo | |
SDCE-2 | Service designer creates a service model from Design Catalog items | |
SDCI-2 | Designer Studio stores and retrieves Design Catalog items | |
SDCE-3 | Ops designer creates monitoring templates with mS data flows → replaced by DCAE-MOD | |
SDCI-3 | DCAE Designer Studio stores and retrieves monitoring flow with mS elements | |
SDCE-4 | Service tester certifies service models for distribution | |
SDCE-5 | Service tester distributes service models | |
SDCE-6 | Distribution Engine publishes service notification to DMaaP. ONAP components subscribe to service notification from DMaaP | |
SDCE-7 | ONAP components retrieve service models from the Design Catalog |
Note: xxxI interface is a SDC internal interface. xxxxE interface is a SDCE external interface
The current API documents can be found at:
- https://docs.onap.org/projects/onap-sdc/en/latest/consumedapis.html
- https://docs.onap.org/projects/onap-sdc/en/latest/offeredapis.html
SDC consumes the following interfaces:
Interface | Purpose | API Spec (Swagger) |
---|---|---|
VNFSDKE-3 | Upload VNF/PNF packagess for test purpose, and retrieve VNF/PNFs packages from the marketplace.Se | |
VNFSDKE-4VN | Request VNF/PNF validation tests and obtain the result |
5. New Capabilities in this Release
SDC Release planning for R8 : SDC R8 Release Planning (link between REQ JIRA and SDC Epics/Stories)
1) Use Case Impact :
No new use case impacting SDC for H release
2) Functional Impact :
ARC reviews of new functional features :
Requirement | Description | Arch Review link | ArchComm decision | Arch Impact ? |
---|---|---|---|---|
ONAP CNF orchestration - Honolulu Enhancements | Approved | No, enhancements to existing feature | ||
PNF Software Upgrade enhancement | Approved | No, enhancements to existing feature | ||
ETSI-Alignment for Honolulu | Approved | No, enhancements to existing feature | ||
ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES (Honolulu) | Approved | No, enhancements to existing feature | ||
ONAP to support Multi Tenancy (part 2) | Approved | No, enhancements to existing feature |
Full Arch review status for functional : Honolulu-R8 Functional Requirements Architecture Reviews
3) Non Functional Impact
Requirement | Description | Arch Review link | ArchComm decision | Arch Impact |
---|---|---|---|---|
Best Practice (to apply to new code) | Pending review | No, mostly only about ensuring proper encryption algorithms | ||
Best Practice (to apply to new code) | N/A (Arch review not required) | No, select most appropriate version for new dependency, if any | ||
Global Requirement (apply to all code) | Closed | No, already done on SDC | ||
Global Requirement (apply to all code) | Closed | No, already done on SDC |
Full Arch review status for non functional : Honolulu-R8 NonFunctional Requirements Architecture Reviews
6.Honolulu Functional View (No change)
The SDC Honolulu view is:
7 SDC Architecture Evolution (optional item)
The goals of the SDC evolution are:
- Seamless Design Time user experience based on user’s roles and design workflow
- Pluggable Framework to integrate multiple external developed design tools into SDC
- One consolidated Design Catalog with common models in SDC to drive ONAP runtime
8 SDC Overall ONAP Architecture Principle Compliance
9 The SDC near term focus on architecture deficiencies are (optional):
User experience:
- Workflow Congfigurator to define service provide specific design workflow
- Workflow guided, role-based user experience
- Function-based (rather than tool based) GUI
Application Layer for Tool Plug-ins
- Provide Plug-in Framework for design tools
- Support standard-based VNF package onboarding tool plug-ins
- Support Onboarding Helm packages
- Provide Data Mapping/Translation/Enrichment to ONAP Standard Internal Model
- Provide tools to support Service Provider's test & validation environment/process for model certification
- Nert term tasks: Integrate Policy Designer, CLAMP designer, CDS - Retire DCAE DS as now replaced by DCAE-MOD
Catalogue & Data Management
- Support common data model as defined by the modelling team
- Model Data Lifecycle Management
- Runtime Distribution Version Management
10 SDC - Current System Deployment Architecture - OOM Helm view
User Experience layer (Frontend Jetty Server)
- supplies the static content of web pages, and all resources that required by the GUI
- serves as a proxy for the REST API requests coming from the GUI
- Every request originating from the GUI is passed to the Jetty front-end server before it is executed.
Application Layer (Backend Jetty Server)
- Containers all the application logic for the SDC.
Catalog/Data Management Layer
- Cassandra is used to store audit data, artifacts and data model objects.