Optimization Service Design Framework
- Sastry Isukapalli
- zhao qing
- nullop
Contents
- 1 Summary
- 2 Rationale and Motivation
- 3 Features and Utility of OOF
- 4 Contributors
- 5 Functional Architecture
- 5.1 Technology Choices
- 5.2 Components of the Core Framework
- 5.2.1 Data Adapter Library
- 5.2.2 Translation Modules
- 5.2.3 Modeling Support
- 5.2.4 Execution Environment
- 6 Simple Example: Budget Constrained Maximum Network Flow Problem
- 7 Initial, Representative Applications
- 8 Other Major ONAP-OOF Use Cases
- 9 Release Planning
- 10 Deployment Process
- 11 Links to Relevant Resources
- 12 Feature Roadmap/Wishlist
Summary
The OOF plans to provide optimization capability as a service for ONAP R2 and beyond. OOF uses a typical optimization construct:
Objective: Maximize/minimize a metric, measured by appropriate key performance indicators (KPIs)
Technology and operating constraints, such as:
Parameter change limits (such as power)
Frequency of changes permitted
Number of parameters that can be changed simultaneously
Data latencies (typically in percentile)
DC compute, network, storage, energy capacity
Location based and time based energy cost
The objective metrics could be throughput (maximize), interference levels (minimize), accessibility/retainability (maximize), cost (minimize) etc. KPIs could be infrastructure utilization statistics provided by ONAP-MC.
The OOF is developed based on the following core ideas:
Most optimization problems can be solved in a declarative manner using a high-level modeling language.
Recent advances in open source optimization platforms allow the solution process to be mostly solver-independent.
By leveraging the library of standard/global constraints, optimization models can be rapidly developed.
By developing a focused set of platform components, we can realize a policy-driven, declarative system that allows ONAP optimization applications be composed rapidly and managed easily
Policy and data adapters
Execution and management environment
Curated "knowledge base" and recipes to provide information on typical optimization examples and how to use the OOF
More importantly, by providing a way to support both "traditional" optimization applications and model-driven applications, we can provide a choice for users to adapt the platform based on their business needs and skills/expertise.
The OOF aims to realize these via a set of initial applications for ONAP use cases that are being developed collaboratively across a broad team.
Rationale and Motivation
Traditional Optimization
Traditionally, optimization applications are tailor-made for specific requirements, and the process for developing an optimization application often involves substantial application-specific "custom code". Any changes in the problem (e.g. new optimization constraints, objectives, or data sources) requires development effort involving code changes in various components of the application. These changes can span aspects such as (a) Optimization Model Specification, (b) Request Handler, (c) Adapters for data and parameters, (d) Application Configuration, (e) Code in custom solver, etc., and involve long development cycles even for simple changes in requirements.
Declarative, Policy- and Model-Driven Architecture for Optimization Applications
The goal of the Optimization Framework is to drastically reduce the amount of such code changes by providing platform-level functionality.