ONAP Casablanca Architecture (v3.0.

1)
For TSC Approval
Chris Donley
Casablanca Deployability Focus

• Deployability: ONAP can be deployed in multiple operator

environments
- Does not imply level of quality
- Continuous improvement, similar to S3P
• ARC priorities supporting deployability
- Microservices
- Modular
- Standards alignment
- API standardization/improvement
- VNF/PNF Onboarding
- Containers
- External controllers

Huawei Confidential
 ONAP Beijing Architecture for Reference
(High-Level View with Projects)
Version 2.0.3
3/15/2018

VNF Validation Program

Modeling (Utilities)

VNF Requirements
Integration
3
 ONAP Casablanca Architecture
(High-Level View with Projects)
Version 3.0.1
7/10/2018

VNF Validation Program

Modeling (Utilities)

VNF Requirements
Integration
4
 Casablanca ARC Recommendations RTSA/µS
• Real-time streaming analytics
- DCAE enhancements to support real-time streaming analysis:
- Enhance DCAE collector to support high volume streaming data collection (Using Socket and/or DDS)
- Add Bulk data collector to DCAE
- Add real-time streaming analytic framework (Flink)
- Support AAF for VNF to DCAE secure communication
- DMaaP Enhancements:
- Add file routing capabilities for bulk data movement

• Microservices:
- Identify and harmonize common components
• For example, reduce number of databases in ONAP using OOM. Projects should use common DB where appropriate or clearly
state why they need an alternate approach. A lot of this work occurred in Beijing release.
- Initial support for K8S VNF in Multi VIM/Cloud
- Include OPNFV Clover project (Spinnaker) in CD pipeline (part of Integration)
- Interest (but no consensus) regarding service mesh/Istio – no recommendation for Casablanca
• Projects are free to experiment with Istio on their own.
• Constrained PoC in MSB with zero impact to other projects
 Casablanca ARC Recommendations APIs & Cloud Region
• External APIs: External actors view ONAP as a black box. This should simplify the ONAP architecture/interfaces,
leveraging the APIs developed by the Ext API project (eg, MEF LSO, TM Forum etc).
- MEF: Legato, Interlude (new functionality for orchestration federation)
- TMF: the API as NBI to BSS and West-East API with another ONAP instances, include (service
catalogue-633, service inventory-638, and service order -641)
• API Improvements: Currently, ONAP internal interactions are mostly handled via REST-like APIs.
- All APIs between internal components & external APIs should be generated by Swagger,
- APIs align with ONAP-published DM,
- Messages exchanged in JSON format.
• API Versioning Support
- https://wiki.onap.org/display/DW/ONAP+API+Common+Versioning+Strategy+%28CVS%29+Proposal
• Cloud Region
- Enhancements in the interactions between OOF and Multi-Cloud for optimal selection of registered cloud
regions for ONAP workload (VNF etc.) deployment
- Multi-Cloud assists OOF by summarizing cloud-specific capability, capacity & cost metrics
- Enhancements in Multi-Cloud while maintaining the separation of concerns between the ONAP service provider
and cloud region provider.
- Multi-Cloud does dynamic modification of the cloud specific VNF deployment template based on specified intent.
 Casablanca ARC Recommendations PNF, Controller, CPU
• PNF Support:
- PNF Registration
- PNF Packaging guideline and verification
- PNF orchestration and lifecycle management (including monitoring, closed loop automation, change management)
• Physical network discovery
- Register 3rd party controller in ESR
- Sync up the abstract topology in A&AI
- Onboard yaml file for the resource in the physical network in SDC.
• CCSDK Enhancements:
- Support configuration and lifecycle management
- Use single controller persona to support (L0-L7) for 5G RAN
• Multi-CPU architecture
- Develop common Docker templates which include multi-CPU arch support
 Casablanca ARC Recommendations SO/SDC/ETSI
• Integrated design environment (SDC) – take incremental steps towards target:
- Run-Time Catalog
- DCAE-DS enhancements to support CLAMP flow design
- Policy Designer integration to support Control Loop MS configuration policies (Xacml) and
Operations Policies (drools).
- Flow Designer - GUI and BPMN artifact generations for SO Change Management support.
• SO Enhancements
- Extend the SO “decomposition” Building Block to support decomposition of Services that
include VNFs and PNFs.
- Model the “Service Instantiation” sequencing relationships [in SDC] that SO must enforce
among the Resources within a Service.
• ONAP to leverage ETSI SOL specifications in applicable projects
- VNF Onboarding (external to ONAP): SOL-001, SOL-004
- Plugged-in VNFM (external to ONAP): SOL-003
- SO-VFC (internal to ONAP): SOL-005
Functional Description of Project Components

Note – The detailed description of features/capabilities/interfaces for each component planned for the
Beijing release will be provided by respective projects.
SO: Service Orchestrator (1/2)

• Service Management Interface

Definition:
• Network Service LCM Interface - Provides functionality for the execution of specified process and automated sequencing of activities, task,
• Actuation Request Interface
• Service Definition Reception interface rules and policies needed for creation, modification, removal of network application, infrastructure services
or resources.
- Supports different specializations with specific orchestration scopes.
- Specialization scopes include, but are not limited to, PNF orchestration, Service and VF scaling, Homing
Service and placement.
Orchestrator

Service Management Interface

Provided Interfaces:
VNF LCM Interface
NF Config Interface
- Service Management Interface
Optimization request Interface
Inventory Service Interface
- Provides the interface to manage the services that orchestration provides.
Transport Service Interface
Network Service LCM interface
- LCM interfaces
- interfaces for service LCM.
- interfaces for VNF LCM.
- Actuation Request Interface
- Provides support of actuation requests towards the services.
SO: Service Orchestrator (2/2)

•
•
Service Management Interface
Network Service LCM Interface
Consumed interface Interfaces:
•
•
Actuation Request Interface
Service Definition Reception Interface
- VNF LCM Interface, from: Application controller
- Optimization Request Interface, from: Optimization Framework
- NF Config Interface, from: Application controller
- Inventory Service Interface, from: Available and Active Inventory
Service
Orchestrator
- Transport Service Interface, from: SDN Controller.
- Network Service LCM interface, from: Virtual Function Controller
- Service Distribution interface, from: Service Design and Creation
Service Management Interface
VNF LCM Interface
NF Config Interface
Optimization request Interface
Inventory Service Interface
Transport Service Interface
Consumed Models:
Network Service LCM interface
- Network Service Descriptor (from SDC)
SDC: Service Design and Creation (1/2)
Definition:
- SDC is the Integrated development platform for modeling.
- SDC provides set of functionalities starting from the VNF onboarding and up to the service distribution.
- SDC provides a set of modeling capabilities including VNF modeling, Service modeling.
VNF-SDK
Dmaap - As part of the work for Beijing SDC is adding the Monitoring template modeling capabilities and work flow
modeling capabilities.
Provided Interfaces:
Service Design and - External API’S
Creation - Retrieve artifacts.
- Query catalog.
- Upload artifacts.
AA&I
APPC - Distribution client
VFC - Java based client for subscribing and receiving notifications from Dmaap regarding Services.
SO
SDN-c - The client provides a way to define what artifacts need to be retrieved from the service.
CLAMP
VID
- The client downloads the artifacts from SDC and publishes a notification regarding its success or failure.
UUI - SDC parser
DCAE
- A java based parser for Tosca.
- The parser allows components to parse the CSAR artifact provided by SDC.
- Generic Designer Frame work
- Infrastructure to support easy integration of new designers into SDC.
- SDC-UI a set of ui components and styles to allow designers the same look and feel as SDC.
SDC: Service Design and Creation (2/2)

Consumed interface Interfaces:

- VNF SDK – SDC can query VNF’s from the marketplace and onboard them into SDC.
VNF-SDK
Dmaap - Publish and subscribe to notifications using Dmaap.

Service Design and

Creation

AA&I
APPC
VFC
SO
SDN-c
Consumed Models:
CLAMP - VNF packages Heat based and Tosca based
VID
UUI
DCAE
 Data Collection, Analytics, and Events
Definition:
• Data collection interface
• Deployment interface DCAE is the ONAP subsystem that supports closed loop control and higher-level correlation for business and operations activities. DCAE
• Config binding interface collects performance, usage, and configuration data; provides computation of analytics; aids in trouble-shooting and management; and
publishes event, data, and analytics to the rest of the ONAP system for FCAPS functionality.

Provided Interfaces:
Data Collection, - Interface 1: Data collection interface (provided by DCAE collectors, consumed by VNFs and others)
- Interface for various FCAPS data entering DCAE/ONAP.
Analytics, and
- Interface 2: Deployment interface (provided by DCAE Deployment Handler, used by CLAMP and other northbound
Events applications/services)
- Interface for triggering the deployment and changes of a control loop
- Interface 3: Configuration Binding Service
- Interface for querying the information of the services that are registered to DCAE Consul

Consumed Interfaces:
• Data movement platform interface (DMaaP) - Interface 1: Data movement platform interface (provided by DMaaP)
•
•
Data enrichment interface (A&AI)
Service model change interface (SDC)
- Interface for data transportation between DCAE subcomponents and between DCAE and other ONAP components
• Policy interface (Policy) - This interface can also be used for publishing events to other ONAP components.
- Interface 2: Data enrichment interface (provided by A&AI)
- Interface used by DCAE collectors and analytics for querying A&AI for VNF information for the purpose of enriching collected
raw data by adding information not contained in original data.
- Interface 2: Service model change interface (Provided by SDC)
- Interface for DCAE Service Change Hander fetching control loop models and model updates.
- Interface 4: Policy interface (Provided by Policy)
- Interface for DCAE Policy Hander fetching configuration and operation policies on control loop and control loop components
from Policy.

Consumed Models: TOSCA models descripting control loop construction (e.g. collection and analytics apparatus)
Holmes

Definition:
Interface 1 - Maintains a series of rules inside to support different kinds of correlation analysis scenarios and control loops.
- It publishes the analysis result to the data bus to feed any components that need the data.

Holmes

Provided Interfaces:
- Rule Management Interface
- Provides the ability to create, updae, delete or query rules.

Interface N
Consumed interface Interfaces:
- Data pub/sub interfaces, from: DMaaP
- Service info query interfaces, from: DCAE
- Service registration and locating interfaces, from: MSB
- Inventory info query interfaces, from: A&AI

Consumed Models
VES Model
Inventory Model
Active & Available Inventory, External Registry

Definition:
• Inventory Service Interface - AAI maintains a live view of services and resources in the network, providing the state and relationships of the service components
• External Register Interface
- Maintains the view of the managed systems services and resources, as well as information of the external systems that ONAP will connect to.
- It provides real-time views of a managed systems resources, services and relationships with each other.
- AAI provides a GUI to provide users the ability to find and inspect inventory data. This includes a free-text search, inspection of specific entities
and their relationships, and aggregated views of data.
Active & Available - AAI also provides a GUI to manage the external system information, including the register/update/delete and query external system.
Inventory, External
Registry Provided Interfaces:
- Inventory Service Interfaces:
- AAI Resources REST API - Provides the ability to store, read, update inventory information
- Gizmo: a low-level REST CRUD API that provides targeted and simple access to entities, relationships, and their properties. Gizmo also
provides lightweight collections, and transactional bulk write support
- Complex Query Interface: AAI Traversal REST API – Provides the ability to perform complex traversals of the AAI Graph
Interface N - External Register interface
- Provides the ability to register/update/delete and read external system information

Consumed interface Interfaces:

- DMaaP
- SDC
- Multivim

Consumed Models: TOSCA Service and Resource Models

AAF Functional Description
• The purpose of AAF (Application Authorization Framework) is to organize software authorizations so that applications, tools and services can
match the access needed to perform job functions. This is a critical function for Cloud environments, as Services need to be able to be
installed and running in a very short time, and should not be encumbered with local configurations of Users, Permissions and Passwords.
• To be effective during a computer transaction, Security must not only be secure, but very fast. Given that each transaction must be checked
and validated for Authorization and Authentication, it is critical that all elements on this path perform optimally.
• AAF contains some elements of Role Based Authorization, but includes Attribute Based Authorization elements as well.
Essential Functional Components:
• The core component to deliver this Enterprise Access is a RESTful service, with runtime instances backed by a resilient Datastore
(Cassandra as of release 1.3)
• The Data is managed by RESTful API, with Admin functions supplemented by Character Based User interface and certain GUI elements.
• The Service accessible by provided Caching Clients and by specialized plugins
• CADI (A Framework for providing Enterprise Class Authentication and Authorization with minimal configuration to Containers and Standalone
Services)
• Cassandra (GRID Core)
Additional Functional Components:
• Secret Management service : This service provides a way to add/delete/retrieve secret domains and secrets within each domain
• Security of private keys using PKCS11 based HSMs: Secures the private keys of CA using PKCS11 based HSMs. Also show cases the HSM
integration with softHSM2.0 and optionally provide a way to secure the softHSM using TPM 2.0 hardware entity.
AAF Functional Description
• CADI stands for Code, Access, Data and Identity, This Framework addresses the Runtime Elements of Access and Identity.
• Many other tools address elements of this vision. For instance, Sonar and Fortify evaluate code for maintainability and
security problems, while Voltage provides encryption for Data at Rest.

However, CADI Framework contributes to these for runtime applications by:

• Code - CADI provides reusable Security Client code, and ties in with appropriate Security Interfaces (i.e. J2EE Standard
Filters)
• Access - CADI provides links to Authorization tool(s) (AAF) for Fine-grained Authorization. Also, data from Identity servers
is also made available to Coders easily. For instance, CADI provides a clean API to read the Course Grained Authorization
information available within the CSP Cookie.
• Data - CADI provides simple setup for certificates needed for TLS connectivity, so that barriers to using HTTPS are greatly
reduced. It also ensures that no one using CADI uses clear-text passwords in Configuration files.
• Identity - CADI Framework obtains the Identity of any callers by delegating to CSO approved Identity servers on behalf of
the client, so that Applications can be assured of who is talking to them.
AAF Functional Description
Entities within AAF
Namespaces
• A Namespace, in AAF, is the ensemble of Roles, Permissions and Identities controllable within the domain assigned to a member of the Organization's chain-of-
command.
• Namespaces are known by domain, in dot-delimited form. ex: com.att.aaf or com.att.wfa, and they are hierarchically managed.
People in Namespaces
• Owner (Responsible)
• A key feature of how AAF works for an Enterprise is by supporting federated responsibility. This responsibility is clearly delineated by the owner entry. Organizations
(i.e. companies) may establish their own policies
Roles
• I) "Roles" is a bit of an overloaded term in Security software. It has unfortunately been typically used as a flat, unscoped Group, known only to the Application.
• Typical examples such as "user" and "admin" have no meaning outside the immediate context of the application. "admin"??? "admin" of what? What are the
behaviors allowed for "admin"? Is the "admin" of Application A, the same as Application B? (answer, no!)
Permissions
Permissions are the other side of the decoupled Authorization equation. Permissions represent some resource that needs to be protected by the Application in question.
examples:
• A GUI Admin page should be available to only those who job function is to administer this app.
• SPI Data that this App accesses should only be accessible to those who are allowed to see SPI data.
• Full data reporting dumps should only be accessible to Audit teams.
AAF Object Model
DMaaP Functional Description
• Data movement as a platform(DMaaP) is a premier platform for high performing
and cost effective data movement services that transports and processes data
from any source to any target with the format, quality, security, and concurrency
required to serve the business and customer needs.
• DMaaP consists of three major functional areas:
1. Data Filtering - the data preprocessing at the edge via data analytics and compression to
reduce the data size needed to be processed.
2. Data Transport - the transport of data intra & inter data centers. The transport will support
both file based and event based data movement. The Data Transport process needs to
provide the ability to move data from any system to any system with minimal latency,
guaranteed delivery and highly available solution that supports a self-subscription model that
lowers initial cost and improves time to market.
3. Data Processing - the low latency and high throughput data transformation, aggregation,
and analysis. The processing will be elastically scalable and fault-tolerant across data
centers. The Data processing needs to provide the ability to process both batch and near
real-time data.
• This service is build using Apache Kafka and Restful API is created for message
publishing, subscribing and admin activities
APPC (1/2)
Definition:
Application Controller (APPC) performs the functions to manage the lifecycle of VNFs and their components.
• It provides a comprehensive set of controller actions such as Configure, Modify Configuration, Start, Stop, Migrate, Restart, Rebuild, and so on. Consult readthedocs documentation
for the full set of APIs offered/supported.
• It supports a set of standard VNF interfaces (Netconf, Chef, Ansible.), and
• Is designed to be self-service using a model driven architecture that provides a layer of abstraction making APPC completely service, VNF, and site agnostic.
Information about the APPC architecture and provided APIs can be found in the APPC User Guide and LCM & OAM API Guides on readthedocs
.

Provided Interfaces: (refer to APPC User Guide for details)

APPC
APPC (2/2)
Consumed Interfaces

APPC

Consumed Models:
• TOSCA Dependency Model
• APP-C also support a variety of models, most of which are created by the APPC Configuration Design Tool (CDT). Examples are:
• Reference Data Model (json)
• VNF Capabilities Model (json)
• Template Model (json or xml)
• Parameter Definition Model (yaml)
CLAMP (1/2)
Definition:
CLAMP is a platform for designing and managing control loops.
It is used to design a control loop, configure it with specific parameters for a particular network service,
then It interacts with other systems to deploy/undeploy and execute the control loop.

Information about the CLAMP architecture and provided APIs can be found in the CLAMP User Guide and LCM & OAM API Guides on readthedocs

Provided Interfaces: (CLAMP doesn’t expose functional relates API’s except the one below, refer to CLAMP documentation for more details)
CLAMP
Interfaces Service Purpose/Comments
HealthCheck REST Health Check of CLAMP instance
CLAMP (2/2)

Consumed Interfaces:

Interfaces Service Purpose/Comments

SDC REST Distribution of service to DCAE
DCAE REST Common Controller Framework
Policy REST(JSON data) Create Configuration and Operational policy

CLAMP

Consumed Models: (No specific models were used in the above interface except for Policy(json))
 Use-case UI

Definition:
• None
- Provides portal for service life cycle management
- Provides portal for VNF alarm and performance
- Provides portal for VM alarm and performance
Usecase UI

Provided Interfaces:
- None
• Catalog Synchronization Interface
• Service Orchestrator Interface
• Inventory Service Interface
• NS/VNF Onboard Interface
• Service Registration Interface
• Data Subscription Interface

Note: Can be more than one page

 Use-case UI

Consumed Interfaces:
• None - Catalog Synchronization Interface, from: SDC
- Service Orchestrator Interface, from: SO
- Inventory Service Interface, from: Available and Active Inventory
Usecase UI - NS/VNF Onboard Interface, from: VF-C
- Service Registration Interface, from: MSB
- Data Subscription Interface, from: DMaaP

• Catalog Synchronization Interface Consumed Models:

•
•
Service Orchestrator Interface
Inventory Service Interface
- Network Service Descriptor
•
•
NS/VNF Onboard Interface
Service Registration Interface
- VNF Descriptor
• Data Subscription Interface

Note: Can be more than one page

 ONAP CLI
Definition:
micro-service discovery commands - Provides Open CLI Platform (OCLIP) – Industry first Model-driven command line interface platform
external system and VNF cloud on-boarding commands
customer and subscription management commands - Provides commands for performing end-end service on-boarding and life cycle management
resource on-boarding commands
Product and service management commands
- Provides command console for Linux and web platforms.
network service life-cycle management commands
Provided Interfaces:
- micro-service discovery
- Provides commands for micro service discovery and registration
- external system and VNF cloud on-boarding
- Provides commands for registering/unregistering VIM, VNFM, EMS and SDNC
ONAP CLI - customer and subscription management
- Provides commands for subscription and service-type life cycle management
- resource on-boarding
- Provides commands for adding VNF modules
micro-service discovery Interface (MSB)
external system and VNF cloud on-boarding
- Product and service management
interface (AAI) - Provides commands for design time creation and management of VF and NS
customer and subscription management
interface (AAI) - network service life-cycle management
resource on-boarding interface (SDC)
Product and service management interface - Provides commands for creating and managing Network services (NS)
(SDC)
network service life-cycle management
interface (SO)
Consumed interface Interfaces:
- REST API from SDC, SO, AAI, MSB.

Consumed Models:
- Open Command Specification (OCS) 1.0
Microservices Bus (1/2)
Service Registration REST Interface
Service Discovery RES Interface
JAVA SDK for Service Registration/Access
Swagger SDK
Definition:
- Provides a reliable, resilient and scalable communication and governance infrastructure to
support ONAP Microservice Architecture(OMSA).
- Provides RESTFul API for service registration/discovery
Micro Services Bus - Provides JAVA SDK for service registration and access
/ Data Movement
- Provides a transparent service registration proxy with OOM-Kube2MSB
- Provides a transparent service communication proxy which handles service discovery, load
balancing, routing, failure handling, and visibility-Internal API Gateway(Implemented) and Mesh
Sidecar(WIP)
Interface N - Provides an External API Gateway to expose ONAP services to the outside world
- Swagger SDK for auto-generate the client SDK in different languages for every micro-services in
ONAP. Also it deploys the generated SDK into the nexus.
Microservices Bus (2/2)

Service Registration REST Interface

Service Discovery RES Interface
JAVA SDK for Service Registration/Access
Provided Interfaces:
Swagger SDK - Service Registration REST Interface
- Provides the RESTFul interface to register ONAP services.
- Service Discovery REST Interface
- Provides the RESTFul interface to discover ONAP services.
Micro Services Bus
/ Data Movement - JAVA SDK
- Provides JAVA SDK to register ONAP services.
- Provides JAVA SDK to access ONAP services.
Note: ONAP components don' t need the MSB interfaces to leverage the transparent service registration
proxy (kube2msb) and communication proxy (API Gateway).
Interface N
-Swagger SDK
- provides Mvn plug-in settings for (JAVA)client sdk generation

Consumed interface Interfaces: (None)

Consumed Models:
- Swagger for RESTFul APIs definition
- Service definition in kubernetes config files for automatically service registration by kube2MSB
 Optimization Framework - R2 (1/4)
Definition:
- ONAP Optimization Framework (OOF) provides functionality for creating and running optimization applications by leveraging
a policy-driven, declarative approach.
• Service Orchestrator (SO) - Supports different specializations (applications) with specific domain and optimization needs.
• Change Management Portal - Initial specialization scopes include, but are not limited to, VNF placement support via Homing and Allocation Service (HAS)
with different use cases, and change management scheduling service.
- For R2, the OOF will support vCPE use case (as a MVP).
- For R2, the OOF will demonstrate an example of Change Management Scheduling Optimization using the OOF design
framework with simple, representative constraints.
Optimization
Framework (OOF) Provided Interfaces:
- Placement Optimization Interface
- Provides functionality for the Service Orchestrator to specify placement services [vCPE use case]
- Change Management Portal Interface
- Provides functionality for calculating schedules that satisfy time constraints and conflicts [R2 focus on a
• Policy Interface demonstration of the design framework; alignment with Change Management scheduling use case]
• Inventory Service Interface
• Service/Policy Models Interface Consumed Interfaces:
• Infrastructure Metrics Interface - Policy Interface, from: Policy
- Inventory Service Interface, from: Available and Active Inventory
- Service/Policy Models Interface, from: SDC
- Infrastructure Metrics Interface, from: Multi Cloud

Consumed Models:
- Policy Models (constraints) and License Models from: SDC
- Infrastructure Metrics Models, from: Multi Cloud
 Optimization Framework - R3+ (2/4)
Note on Functionality for R3 and beyond:
While the items listed below are not part of MVP for R2, the OOF team is initiating discussions and collaborations on these during
the R2 time frame, so that the OOF is aligned with the use cases that will mature in R3 and beyond.
• Service Orchestrator (SO)
• Change Management Portal Additional Definitions for R3 and beyond:
- For R3 and beyond, the OOF will focus on supporting multiple R3 and beyond use case (along with R2 use cases)
[supporting VoLTE, VNF/Service scale-in/out (higher order control loop), and RAN-5G].
- Synchronization with Change Management Scheduling use case.
- Providing additional sample/example optimization applications as documentation.
Optimization - Proving initial Knowledge Base on OOF (building blocks and recipes for creating complex applications).
Framework (OOF)
- Further alignment with S3P objectives.

Additional Provided Interfaces for R3 and beyond:

• Policy Interface - Placement Optimization Interface
- For R2, the focus is on supporting vCPE use case;
• Inventory Service Interface - for R3 and beyond, the OOF will also support VoLTE, VNF/Service scale-in/out (higher order control loop), and RAN-5G.
• Service/Policy Models Interface - Change Management Portal Interface
• Infrastructure Metrics Interface - For R2, the focus is on a demonstration of OOF with simple, representative constraints;
this effort will be aligned with the Change Management scheduling use case (for R3 and beyond)
R3 and Beyond Additional Consumed Interfaces for R3 and Beyond:
• Application Metrics Interface - Application Metrics Interface, from: DCAE [R3 and Beyond]
- These are in addition to Policy, Inventory, SDC Models, and Infrastructure metrics from R2

Additional Consumed Models for R3 and beyond:

- Application Metrics Models, from: DCAE
Optimization Framework - Interface Definitions (3/4)

Optimization Request Interface

Provided Service Homing Service API (HAS-API)

Supplementary The OOF will provide a list of possible candidates for placement, which the service orchestrator can
Information use to instantiate the service
Interface Provider(s) Optimization Framework

Provided Capabilities - Optimization Information Request

Optimization Framework - Interface Definitions (4/4)

Scheduling Optimization Request Interface

Provided Service Change Management Scheduling API (CMSO API)

Supplementary The OOF will provide a possible schedule of VNF actions (e.g. upgrades) that satisfy the constraints
Information on availability periods and constraints related to conflicts
Interface Provider(s) Optimization Framework

Provided Capabilities - Optimization Information Request

 VNF SDK (VNF package validation) (1/2)

Definition:
- Provides functionality to upload, verify, and download VNFs
- VNF Vendors upload VNFs through the Marketplace portal
- Marketplace runs package validation tests
- VNFs are made available for Onboarding

Marketplace API
Marketplace API:
- Upload/Re-upload VNF
- Upload VNFs to the Marketplace
VNF SDK
Marketplace - Download VNF
- Download VNFs
- Query VNF
- Query VNFs by CSAR ID or conditions (name, version, type, provider)
- Delete VNF
- Delete VNF from the Marketplace

Consumed Models: SOL-004 (Beijing)

Note: Can be more than one page
VNF SDK - Interface Definitions (2/2)

Marketplace API

Provided Service Upload, Download, Query, Delete

Supplementary The VNFSDK APIs are documented on the ONAP Wiki:

Information https://wiki.onap.org/display/DW/API+Documentation
Interface Provider(s) VNF SDK Marketplace

Provided Capabilities VNF Pre-onboarding upload/download/validation/query/delete

VF-C Components
NFVO Functions
SO Policy UUI • Support NS Lifecycle Management including NS
Os-Ma-nfvo instantiate, scale, heal, operate (query
/update/…)and terminate. Most of NSLCM interfaces
NFVO VNF Package
NS Package align with SOL005 Os-Ma-nfvo reference point
( VNFD)
Instantiate ( NSD) • Support integration with multi VNFMs via drivers
Terminate
which include vendors VNFM and generic VNFM.
The interfaces between NFVO and driver comply
Scale
with Or-Vnfm reference point.
Operate • Support integration with multi VIM via Multi-Cloud
Heal • NFVO also supports integration with vendor EMS
via driver
Or- Vnfm Or- Vnfm
Driver VNF Package
Driver GVNFM Functions
Or-Vi ( VNFD)
SVNFM GVNFM EMS • Support VNF Lifecycle Management, including VNF
deploy, scale, heal, operate (start/stop/restart/…),
Vi-Vnfm
update and terminate, etc
Multi-Cloud • Support multiple VNFs and multi-type VNFs from
Vi-Vnfm Vi-Vnfm
different vendors
NFVI&VIM • Support multiple VIM environments and multi-type
VM environments based on VM or Docker

37
 VF-C – NFVO (1/2)

• Network Service LCM Interface

• VNF Operation Granting Interface
•
•
NS package management Interface
VNF package management interface
Definition:
- Provides reference implementation of NFVO in ETSI MANO architecture
- Provides Network service life cycle management
- Provides NS/VNF layer’s FCAPS management

NFVO

Provided Interfaces:
- Network Service LCM interface
- Provides Network Service LCM interface
VNF LCM Interface
Inventory Service Interface
(NS instantiate/scale/heal/terminate/query/…)
Catalog Synchronization interface
Generic VIM Interface
- VNF Operation Granting interface
Date report interface
Tosca parser interface
- Provides VNF Operation Granting interface and make granting decision
Optimization Request Interface - NS package management interface
- Provides runtime NS package management interface
- VNF package management interface
- Provides runtime VNF package management interface
Note: Can be more than one page
 VF-C – NFVO (2/2)

• Network Service LCM Interface

• VNF Operation Granting Interface
• NS package management interface
• VNF package management interface
Consumed Interfaces:
- VNF LCM Interface, from: Generic VNFM controller, SVNFM
- Inventory Service Interface, from: Available and Active Inventory
- Catalog Synchronization Interface, from: SDC
NFVO - Generic VIM Interface, From: Multi-cloud
- Data report Interface, From: DCAE
- Tosca parser Interface, From: Modeling
- Service registration and discovery, From: MSB
VNF LCM Interface - Optimization Request Interface, from: Optimization Framework -TBD
Inventory Service Interface
Catalog Synchronization interface
Generic VIM Interface
Data report interface Consumed Models:
Tosca parser interface
Optimization Request Interface - Network Service Descriptor
- VNF Descriptor
- VES data format
- Bpmn Workflow

Note: Can be more than one page

 VF-C - GVNFM
Definition:
• VNF LCM Interface - Provides the Generic VNFM
- Provides the VNF life cycle management
- Supports NFVO to implement Network service LCM management

Provided Interfaces:
GVNFM - VNF LCM interface
- Provides the VNF LCM interface (VNF instantiate/terminate/query/…)

Consumed interface Interfaces:

• Catalog and notification Interface
- Catalog and notification Interface, from: NFVO
•
•
Inventory Interface
Tosca parser Interface
- Inventory Interface, from: A&AI
•
•
Generic VIM Interface
VNF config interface
- Tosca parser Interface, From: Modeling
- Generic VIM Interface, From: Multi-cloud
- Service registration and discovery, From: MSB
- VNF Config interface: from VNF -TBD
- :
Consumed Models
- VNFD
Note: Can be more than one page
ONAP Portal
Definition:
- Portal is a platform that provides the ability to integrate different ONAP applications into a centralized Portal Core.
Portal Admin Interfaces - It allows decentralized applications to run within their own infrastructure while providing common management services and
SDK Jars (Policy, VID, AAI, and SDC)
connectivity.
- It provides capabilities including application onboarding & user management, and hosted application widgets.
- Using the provided SDK, application developers can leverage the built-in capabilities (Services / API / UI controls) along with
bundled tools and technologies.
ONAP Portal

Provided Interfaces:
- Portal Admin Interfaces
- Onboarding and User management
- SDK Module
AAF - SDK will be used as a base for any ONAP application being built.
- Components using SDK jars: Policy, VID, AAI, and SDC
- SDK bundles together a host of different tools, technologies, and standards that will assist the teams during the
development phase.
- SDK includes reusable UI components, authentication & authorization components, visualization & reporting engine,
collaborative services, workflow manager, GIS / Map, web component, and widget development framework.

Consumed interface Interfaces:

- Restful APIs for fetching available roles to portal’s onboarded application users. from: AAF

41
Logging-analytics (1/2)

Definition:
Kibana
- Provides ELK stack where logs are streamed from filebeat sidecar containers per component

Logging-analytics

Provided Interfaces:
- Kibana UI:
- dashboard for indexed logs
- Logstash:
filebeat
- Consumes logs pushed by filebeat containers into elasticsearch indexer

Consumed interface Interfaces:

- Filebeat container per microservice exposing logs through a Kubernetes PV:

Consumed Models: none

 Logging-analytics (2/2)

Logging-analytics Interface

Provided Service Kibana dashboard, search service on top of elaticsearch index of ONAP logs – via filebeat

Supplementary
Information
Interface Provider(s) AA&I, APPC, SO, Policy, Portal, SDC, SDNC, VID

Provided Capabilities - Search logs using lucene search format

- Dashboard of configurable search views of logs
 Multi-Cloud Adaptation (1/2)
Definition:
• Resource LCM Interface
• VIM registry/un-registry Interface - enable ONAP to deploy and run on multiple infrastructure environments, including OpenStack and its
•
•
VIM FCAPS management Interface
VIM capacity/capability query
different distributions, public and private clouds, and micro services containers, etc.
- provide a Cloud Mediation Layer supporting multiple infrastructures and network backends so as to
effectively prevents vendor lock-in.
- decouple the evolution of ONAP platform from the evolution of underlying cloud infrastructure, and
Multi-Cloud minimizes the impact on the deployed ONAP while upgrading the underlying cloud infrastructures
adaptation
independently.

Provided Interfaces:
- Resource LCM interface
- Support VNF instantiation/termination
ONAP Interface (Resource create/delete/update/query)
Inventory Service Interface
DMAAP interface - VIM registry/un-registry Interface
Logging interface
The third party Cloud interface - Support registry/un-registry of multiple clouds
OpenStack Interface
VMware VIO interface (VIM create/delete/update)
Wind River Titanium Interface
- VIM FCAPS management Interface
- Support FCAPS required data collection, event/alert/metrics federation functions
(message pub/sub)
- VIM capacity/capability query
- Support placement and scheduling purpose
(capacity/capability query/report)
 Multi-Cloud Adaptation (2/2)

• Resource LCM Interface

Consumed Interfaces:
• VIM registry/un-registry Interface - ONAP
• VIM FCAPS management Interface
• VIM capacity/capability query - Inventory Service Interface from Available and Active Inventory
- Message pub/sub interface from DMAAP
- Logging interface from Logging project
Multi-Cloud - The third party Cloud API
adaptation - OpenStack Interface
- Ocata
- Mitaka
- VMware VIO interface (Ocata)
ONAP Interface
- Wind River Titanium Interface (Mitaka)
Inventory Service Interface
DMAAP interface
Logging interface
The third party Cloud interface
Consumed Models:
OpenStack Interface
VMware VIO interface
- Existing
Wind River Titanium Interface
- VES data format
- Underworking
- Hierarchical Infrastructure Resource Information Model
- FCAPS Data Model
ONAP Operations Manager (OOM)

Definition: OOM is the life cycle manager of the ONAP platform (i.e. SDC, SO, SDNC, etc.). OOM uses
the Kubernetes container management system and Consul to provide the following functionality:
Deployment - with built-in component dependency management (including multiple clusters,
federated deployments across sites, and anti-affinity rules)
Configuration - unified configuration across all ONAP components
Monitoring - real-time health monitoring feeding to a Consul GUI and Kubernetes
Restart - failed ONAP components are restarted automatically
Clustering and Scaling - cluster ONAP services to enable seamless scaling
Interface 1
Upgrade - change-out containers or configuration with little or no service impact
Deletion - cleanup individual containers or entire deployments
OOM supports a wide variety of cloud infrastructures to suit your individual requirements.
ONAP Operations
Manager
Provided Interfaces: Consul GUI for health monitoring, Kubernetes CLI for platform management

Consumed interface Interfaces: None

Interface N
Consumed Models: ONAP Deployment Specifications, ONAP Component Configuration Artifacts
Policy Framework (1/2)

Policy CRUD interface

Policy deployment interface
Definition:
Policy model CRUD interface - Provides a logically centralized environment for the creation and management of modifiable
configurations, rules, assertions and/or conditions to provide real-time decision making on
conditions and events that underlie ONAP’s control, orchestration, and management functions
Policy Framework - Supports specification, decomposition, distribution and enforcement for various types of policies
such as microservice configuration policy, operational policy, decision policy, guard policy, etc.
- Policy scopes include, but are not limited to, infrastructure/network management, products and
services, operation automation, and security.

Message Router Pub/Sub Service Interface

Provided Interfaces:
Service Registration/Discovery Interface
VNF/VM LCM Interface - Policy CRUD interface:
- Provide UI and API options to create/query/update/delete configuration, decision and
NF Config Interface
Inventory Service Interface
Network Service LCM Interface
Service Distribution Interface operational policies
- Policy deployment interface:
- Provide UI and API options to deploy configuration, decision and operational policies
- Policy model CRUD interface:
- Provide UI and API options to create, query, update and delete policy models
Policy Framework (2/2)

Policy CRUD interface

Policy deployment interface
Consumed interface Interfaces:
Policy model CRUD interface
- Message Router Pub/Sub Service Interface, from: Data Movement as a Platform
- Service Registration/Discovery Interface, from: Microservices Bus
- VNF/VM LCM Interface, from: Generic NF controller
Policy Framework - NF Config Interface, from: Generic NF controller
- Inventory Service Interface, from: Available and Active Inventory
- Network Service LCM Interface, from: Service Orchestrator
- Network Service LCM Interface, from: Virtual Controllers (APPC and VFC)
- Service Distribution Interface, from: Service Design & Creation
Message Router Pub/Sub Service Interface
Service Registration/Discovery Interface
VNF/VM LCM Interface
NF Config Interface
Inventory Service Interface
Network Service LCM Interface
Service Distribution Interface
Consumed Models
- Operational policy model
- Configuration policy model
- Resource model in the catalog
- Service model in the catalog
 Key
SDN-C Functions CE-x Controller External API

CI-x Controller Internal API

Artifact Closed Loop Actions Inventory

Orchestration
• SDN-C configures and maintains the health of L1-3 VNFs/PNFs Distribution Policy Updates
and network services throughout their lifecycle Service Design
Orchestration
Data Collection, Active & Available
& Creation Analytics & Events Inventory
• Programmable network application management platform
MSB/Data Movement
‒ Behavior patterns programmed via models and policies CE-1 CE-2 CE-3 CE-4

‒ Standards based models & protocols for multi-vendor implementation SDN-C API Handler
‒ Extensible SB adapter set supporting various network config protocols, CI-1 CI-2 CI-3
including 3rd party controllers
Repository Operational Tree/
‒ Operational control, coordinated state changes across devices, source of Service Control Config Tree
telemetry/events, etc. Processing CI-5 (Service Model)
NB Service/Network Yang Models CI-4
• Manages the health of network services & VNFs/PNFs in its scope Service Logic
IP/VRF Assign

MSB/Data Movement
Service L2 Service Create
Configuration Templates
‒ Policy-based optimization to meet SLAs Logic L3 VPN Service Create
Service/Network Design & Service SD-WAN Create
‒ Event-based control loop automation to solve local issues near real-time Engineering Rules Logic TE Tunneling

‒ Action executor for outer control loop automation

Policies
SB Device Yang Models
…
Service
BGP Config
SW Upgrade CI-7
Assigned Resources Inventory:
Service* Topology &
Logic … VNF/PNF State
• Local source of truth
CI-6
‒ Manages inventory within its scope *Not E2E service view. The “Service” view in the
SDN Controller is limited its scope of control
‒ All stages/states of lifecycle
Adapters
‒ Configuration audits
• Key Attributes of Controllers
Multi-Cloud
Network
Adapter
NetConf/
YANG
OpenFlow
BGP LS/
PCEP … Others
External
System
Adapter (s)
‒ Intimate with network protocols CE-5 CE-6
‒ Manages the state of services MSB/Data Movement
‒ Single service/network domain scope per instance External
Multi-VIM/Cloud VNFs 3rd Party Controllers
PNFs Element Mgt. Systems
 Key
SDN-C External/Internal Interface Definitions CE-x

CI-x
Controller External API
Controller Internal API

Artifact Closed Loop Actions Inventory

Distribution
Orchestration
Policy Updates Interface Definitions Beijing Release
Service Design Data Collection, Active & Available
Orchestration
& Creation Analytics & Events Inventory CE-1 Distribution of artifacts from Service Design and Creation (SDC) Yes - TOSCA only
MSB/Data Movement CE-2 Service requests from Orchestration (SO) Yes
CE-1 CE-2 CE-3 CE-4

SDN API Handler CE-3 Closed Loop action requests from Data Collection, Analytics & Events Not in scope
Controller CI-1 CI-2 CI-3 (DCAE)/Policy
Repository Operational Tree/
Service Control Config Tree CE-4 Inventory retrieval from Active & Available Inventory (A&AI) by Service Logic Yes – push/pull (no
Processing CI-5 (Service Model) Inventory updates to Active & Available Inventory by Assigned Resources Inv DMaaP topic subscription)
NB Service/Network Yang Models CI-4
Service Logic
CE-5 Configuration requests for cloud infrastructure networking Not in scope
MSB/Data Movement

Service IP/VRF Assign

Configuration Templates L2 Service Create
Service/Network Design &
Logic
Service L3 VPN Service Create
Lifecycle management requests to Multi-Cloud (e.g., stop/start VM)
Engineering Rules Logic SD-WAN Create
Policies … TE Tunneling
BGP Config
Assigned Resources Inventory:
Service* Topology &
CE-6 Lifecycle management or configuration requests to an external controller or Yes
SB Device Yang Models Service
Logic SW Upgrade
CI-7
VNF/PNF State
system that has responsibility of the target VNF
…

CI-6 CI-1 API Handler looks up or retrieves the corresponding Service Logic instance that Yes
*Not E2E service view. The “Service” view in the
SDN Controller is limited its scope of control maps to NB service request (service/network yang)
Adapters CI-2 API Handler calls Service Control Processing to perform the Service Logic on the Yes
target service or network
Multi-Cloud
Network
Adapter
NetConf/
YANG
OpenFlow BGP LS/
PCEP … Others
External
System
Adapter (s)
CI-3 Prior to CI-2, API Handler might query the (in-memory) Operational/Config Trees Yes
CE-5 CE-6 for the network or service details (if already existing)
MSB/Data Movement
External CI-4 Service Control Processing retrieves the Service Logic, Config Templates, Yes
Multi-VIM/Cloud VNFs 3rd Party Controllers Engineering rules, and Policies as part of processing the requested action
PNFs Element Mgt. Systems
CI-5 Service Control Processing queries and/or updates Operational/Config Trees as Yes
part of making changes to the network (VNFs/PNFs)
CI-6 Service Control Processing requests adapter layer to update/configure VNF/PNF Yes
update using the appropriate adapter for the VNF/PNF
CI-7 Service Control Processing updates the local Assigned Resources Store/Inventory Yes
once network updates are made successfully
External API Definition & Interfaces (1/2)

Definition:
• Service Catalog
- ONAP External APIs expose the capabilities of ONAP. They allow ONAP to be viewed as a “black box” by
• Service Ordering providing an abstracted view of the ONAP capabilities.
• Service Inventory
- External APIs support that an external consumer of ONAP capabilities can be authenticated and authorized.
These APIs can also be used for connecting to systems where ONAP uses the capabilities of other systems.
- Provides a clear and unambiguous ONAP service abstraction so that the BSS/OSS can exchange service
External APIs requirements and service capabilities in a common and consistent fashion.

SDC: Catalog
Provided Interfaces:
SO: Service Instantiation - Service Catalog Interface
A&AI: Inventory Service Interface
- Provides an external view of requestable ONAP Services and the retrieval of the associated Service
template (model)
- Service Ordering Interface
- Provides a mechanism for placing a service order with all of the necessary order parameters
represented on the Service template. It allows users to create, update & retrieve Service Orders and
manages related notifications.
- Service Inventory Interface
- Provides a consistent mechanism to query the Service inventory from an external perspective.
External API – Consumed Interfaces/Models (2/2)

Consumed Interfaces:
•
•
Service Catalog
Service Ordering
- SDC: Catalog
• Service Inventory - SO: Service Instantiation
- A&AI: Inventory Service Interface

External APIs

SDC: Catalog
SO: Service Instantiation
A&AI: Inventory Service Interface
Consumed Models:
- Service Descriptor (TOSCA YAML Service Descriptor)
External API – Service Catalog (1/3)

Service Catalog

Provided Service Provides an external view of requestable ONAP Services and the retrieval of the associated Service
template (model)
Supplementary Service Models are TOSCA representations of the Services that may be requested.
Information
Interface Provider(s) External API

Provided Capabilities • Query Service Catalog

• Retrieve Service Model
External API – Service Ordering (2/3)

Service Ordering

Provided Service Provides a mechanism for placing a service order with all of the necessary order parameters
represented on the Service template. It allows users to create, update & retrieve Service Orders
and manages related notifications.
Supplementary Service Models are TOSCA representations of the Services that may be requested.
Information
Interface Provider(s) External API

Provided Capabilities • Place Service Order

• Query Service Order
• Retrieve Service Order
• Delete Service Order
• Retrieve Service Order State
• Subscribe to Service Order Notifications
• Receive Service Order Notifications
External API – Service Inventory (3/3)

Service Inventory

Provided Service Provides a consistent mechanism to query the Service inventory from an external perspective.

Supplementary
Information
Interface Provider(s) External API

Provided Capabilities • Query Service Inventory

• Retrieve Service
• Retrieve Service State
MUSIC- Multi-Site State Coordination Service

Definition: MUSIC is a multi-site state coordination/management service for a single operator with a rich suite of recipes that
MUSIC API
ONAP components/micro-services can simply configure and use for their state-management needs both within and across sites. At
its core, MUSIC provides a scalable sharded eventually-consistent data-store (Cassandra) wherein the access to the keys can be
protected using a locking service (built on Zookeeper) that is tightly coupled with the data-store.

MUSIC (Multi-site State MUSIC also supports Consul based distributed KV Store and its features include ability to store default configuration settings,
Coordination Service )
dynamic changes to the configuration and propagating the changes to running service instances

Provided Interfaces:
None.
- The MUSIC API is a REST API used to read and write state and manage access to it through a
locking service.
- API to manage (Add/Modify/Delete) configuration/settings.

Consumed Interfaces - None.

Consumed Models - None.