TOSCA Defined Control Loop

Lifecycle Management Demo

Zu Qiang ([Link]@[Link])
Liam Fallon ([Link]@[Link] @liamfallon)
Contents

• Overview and Progress

• Technical Description
• Demo
• Summary
Overview and Progress
Background
SDC
• ONAP architecture is inspired by
Configuration
Parameters
Control Loop and Autonomic
Management research
• ONAP generalizes design time and
CLAMP run time Control Loop support
Configuration Configuration • Microservice definitions deployed
Parameters Parameters
beforehand
• Policy Types and rule sets
DCAE Policy FW
Microservice ControlLoopEvent
Policy
separately deployed beforehand
Microservice
closedLoopControlName
Policy
• CLAMP configures the parameters
Microservice
and starts control loop microservices
and creates policies for control loops
Policy
PoCs in Rel H and Rel G

• Goals
– Demonstrate Control loops themselves can be defined and
deployed using TOSCA
– Use a design time catalogue for Control Loops for a complete
storage of all the artifacts from different DT systems
– Introduce the Control Loop “Participant” concept to allow any
component to partake in a control loop
– propose a Control Loop Run Time API to provide more abstract LCM
• Participating Companies
– Ericsson
– AT&T
– Bell Canada
CL Architecture in PoC (Rel G/H)
ONAP Run Time
CL Run Time

ONAP Design Time Execution Execution

Control Monitoring
CL Design Studio

CL Catalogue
CL
g
onin
Inventory
m is s i
REST API Design Time
Com
Instantiation Monitoring
Catalogue

CL definition DmaaP
in TOSCA
CL CL CL
Participant Participant Participant
Framework

●PoC focus in Release G: DT DCAE Policy

Catalogue and TOSCA Handling PMSH Rules metadata

●PoC focus in Release H:

Commissioning and Participants xNF
Business Requirements: ONAP Rel I
• Executive Summary: CLAMP (Control Loop Automation Management Platform) functionalities, recently moved to Policy
project , want to provide a Control Loop Lifecycle management architecture. A control Loop is a key concept for Automation
and assurance Use Cases and remain a top priority for ONAP as an automation platform. This requirement wants to improve
Control Loop LCM architecture focusing on an abstract CL management logic , providing a common CL Design time catalogue
with a generic CL definition, isolating CL logic vs ONAP component logic and elaborate API to integrate with other design
systems as well as 3PP component integration. PoCs have been progressed in ONAP Rel G and H in this area, CL LCM
redesign has reached a relevant viable set of features and it is ready to be moved in Rel I to mainstream as part of the Policy
framework.
• Business Impact: Deployment and orchestration of automation and control loop use cases across CNFs, VNFs and PNFs in
a model driven way simplifies the network management. Enables operators and service providers to manage the Life Cycle of
a Network Service. Assuring continuity of operation of services is crucial for production and carrier grade environments. The
actualization or upgrades of software and in consequence required changes in the service model is a natural part of service
instance life cycle. Without the support of ONAP service update with schema change, service life cycle management by
ONAP can be very difficult which can impact the quality and continuity of services.
• Business Markets: All operators and service providers that are using ONAP for automation and assurance.
• Funding/Financial Impacts: CL LCM wants to reduce operational expense and its abstraction will provide an added value
with multiple integration points.
• Organization Mgmt, Sales Strategies: There is no additional organizational management or sales strategies for this
requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a
service provider.
Istanbul Status

• The ONAP CLAMP project was subsumed into the the ONAP Policy
Framework Project
• TOSCA Control Loop Life Cycle Management is released in the Policy
Framework, mainly in policy/clamp but also used and added code in
common Policy repos
• New components released
– New TOSCA Control Loop Runtime component released
– New Participant components for Kubernetes, HTTP, and Policy released
• Policy GUI updated
– Supports commissioning of control loop definitions into the Control Loop Runtime
– Supports creation and parameterization of new control loop instances
– Supports management of the life cycle of control loop instances: Instantiation, state
change, monitoring, and deletion
• Public Rest APIs available for all operations supported by the GUI
Roadmap

Rel K
Rel G Rel H Rel I Rel J
+
üa PoC üa PoC üMove to mainstream üIntegration with üCL element design
üDesign Time üRun Time Catalogue, within Policy repo other design studio tools
Catalogue üRun Time Inventory üIntegration with (DCAE-MOD / SDC) üCL definition
üCommissioning üCL participants in CLAMP üCL onboarding composition tool
phase DCAE, and Policy üFull release of üSupport for existing üCL participant in SO
üSupporting PMSH Runtime and CLAMP use cases üCL participant in CDS
use case participant üSupport service üIntegration with 3rd
components automation / party components
üCommissioning of assurance, e.g., üCL participant
Control Loops over network slicing use framework and
REST case documentation.
üSupport xNF üSupport statistics
automation / over Prometheus
assurance use case
(PMSH)
Highlights for Jakarta

• Support for Control Loop design

– Onboarding of Control Loop Elements in SDC
– Composition of Control Loops in SDC
– Distribution and commissioning of Control Loops using the SDC
• Server Improvements
– Spring Framework for Persistence
– Better support for control loop updating
– Statistics using Prometheus
• TCA Use case implementation
– Support for Cloudify is being removed from DCAE in Jakarta
– TCA based control loops planned to be implemented using TOSCA approach
• Proposal: Automation Composition Management
– Proposed PoC in Jakarta
– Generalization of the concept to include use cases beyond control loops
– Use cases with arbitrary components working together to deliver a feature such as
open loops or collections of features
Automation Composition Management

See the Automation Composition Management Wiki Page

Technical Description
What is Supported?

• Managing the definition of Control Loops

• Managing Control Loop Commissioning and
Decommissioning
• Managing the parametrization of Control Loops
• Managing the Control Loop life cycle
– Instantiation
– Status Monitoring
– State Change
CL Target Architecture
ONAP Run Time
CL Run Time
CL & CL Elements
ONAP Service Design & Creation Execution Instances Inventory
Control
CL Design Studio
CL Definition Execution
Other Design Adaptation CL Instance
Composition Monitoring
Studio Env
Layer CL Definition &
Catalogue CL Element
Execution
CL Element(s) LCM operations
Supervion
n in g
Definition is s io
CL onboarding Design Time Co m
m

Catalogue
Dmaap

CL CL CL CL CL
Participant Participant Participant Participant Participant

DCAE Policy CDS SO Other

Platform
PMSH Rules Blueprint Workflow Service

xNF
Control Loop Target Architecture
ONAP App Management Architecture

a apacpc
µµµcµ
p

c
µ
µ

c µ p c
a
µ
Terminology and Concepts
Control Loop Life Cycle Management
Demonstration
PMSH Control Loop
1 1
1. PMSH uses CBS for new 2 3
xNFs or for config changes
2. If a change is detected,
PMSH fetches xNF
information from A&AI and
triggers a control loop
execution
3. PMSH prepares a
subscription change 4
4. PMSH sends subscription
change to Policy
5. Policy executes blueprint on
CDS
6. CDS sends new 5
configuration to xNF
(Simulated in the demo) 6 xNF
LCM of PMSH Control Loop
CL Definition
1. Control Loop Definition is Commissioned into (TOSCA) GUI
Runtime
2. Control Loop instance is created and ONAP
parameterized CL Design CL Runtime

3. Control Loop Instance is instantiated by

changing its state to Passive: Dmaap

a. PMSH microservice is created in DCAE using

the K8S Participant K8S HTTP Policy CDS
Participant Participant Participant
b. PMSH microservice is configured using the (DCAE) PMSH Config
HTTP Participant PMSH Policy CDS
PMSH MS
c. PMSH Policy is deployed using the Policy rules Blueprint
CL Participant
Participant
4. Control Loop Instance is now in service and xNF
CL Element
can be triggered and executed Instance
5. Control loop instance is brought out of
service by changing its state to Uninitialized
CL Instance
6. Control Loop instance is removed
Demonstration

See the LFN Developer Event Minutes page

for this session
Available resources
• A recording of this entire session
• The session slides
• A recording of the demo
Summary
Summary

• TOSCA defined Control Loop functionality is now released and is available in

ONAP
• SDC support, support for more use cases, and improvements are coming in
Jakarta
• Proposal to generalize the approach as “Automation Composition
Management”
• Intention to create a PoC in ETSI ZSM to show the benefits of ONAP’s closed
loop solution and compliance with ZSM specifications. See session on TCC
Generic Network Management on Thursday
• Functionality is available for use in your Control Loop use case
• Full documentation is available in the ONAP documentation here
• Contact us anytime on the Policy Framework channels for more information
Backup Slides
Scalability and Resilience

• The CLAMP runtime is stateless, state preserved in database.

• Participant communication is asynchronous and state handling is
designed to be “eventually consistent”
• Participants cooperate with the CLAMP runtime, all updates to
participants and state change requests are supervised
• More than one CLAMP runtime can be deployed and
REST/supervision operations on Control Loop Instances can run in
parallel
• Many participants of a particular type can exist, load balancing can
be done by the CLAMP runtime and/or independently by
participants