Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Page Status: Updated for Jakarta -  
Component Status: Pending PTL updates and ArchCom Review

Last Reviewed on:

Certified by:

OOF (ONAP Optimization Framework):

1. High Level Component Definition and Architectural Relationships 


2. API definitions

OOF provides the following interfaces:

Interface NameInterface Definition Interface CapabilitiesAPI Spec (Swagger)
OOFE-1
  • Homing
  • Traffic Distribution

It enables placement based on a wide variety of policy constraints including capacity, location, platform capabilities, and other service specific constraints. 

https://docs.onap.org/projects/onap-optf-osdf/en/latest/sections/offeredapis.html
OOFE-2PCI/ANR OptimizationEnables PCI/ANR optimization API for SON.https://docs.onap.org/projects/onap-optf-osdf/en/latest/sections/offeredapis.html
OOFE-4Route Optimization

Provides an interface for Router Optimization and inter-domain route optimization.

https://docs.onap.org/projects/onap-optf-osdf/en/latest/sections/offeredapis.html

OOFE-5OOF Model AdministratorThis is for the OOF Model Administrator API.  This API is a way to dynamically change the optimization models that will be used to find solutions for various optimization problems.  This API will be used to Create, Update, or Delete Models.
OOFE-6

Network Slicing

This interface enables slice selection recommendations (NST, NSI, NSSI, Slice Profiles), as well as slice termination recommendations (NSI, NSSI).

Note:   xxxI interface is a Component internal interface.  xxxxE interface is a component external interface

The current API documents can be found at:

OOF consumes the following Interfaces:

Interface NamePurpose Reason For UseAPI Spec (Swagger)
CPS-1

For fetching RAN configuration related info (starting with coverageArea → TA List mapping in H-release)

Replacement of Config DB client with CPS client for SON optimization

CPS-TBDMT Service

https://github.com/onap/cps/blob/master/cps-rest/docs/api/swagger/openapi.yml

SDNCE-1For PCI/ANR optimization, OOF Retrieves the Cellsite inventory details from the configdb API, which is hosted as part of the SDNC/R componenthttps://github.com/onap-oof-pci-poc/sdnc/blob/master/ConfigDB/swagger-json/swagger.json
AAIE-1OOF interfaces with AAI to retrieve the inventory

OOF consumes a wide variety of inventories from AAI. It can be found under the API section of AAI

https://docs.onap.org/projects/onap-aai-aai-common/en/latest/platform/offeredapis.html

MCE-5

OOF queries Multicloud for real-time available capacity information

https://docs.onap.org/projects/onap-multicloud-framework/en/latest/MultiCloud-APIv0-Specification.html
MUSICI-1OOF interfaces with MUSIC to persist service state.https://docs.onap.org/en/elalto/submodules/music/distributed-kv-store.git/docs/offeredapis.html
SDCE-1OOF interfaces with SDC to retrieve slice template informationhttps://docs.onap.org/projects/onap-sdc/en/latest/offeredapis.html
DESE-1OOF interfaces with DES to retrieve the PM/KPI data of the cells for ML-based decision making.DES Swagger reference
CONSULE-1OOF interfaces with consul for configuration managementhttps://www.consul.io/api-docs/kv
ETCDI-1OOF interfaces with ETCD to persist service state. ETCD is one of the alternative backend for MUSIC https://etcd.io/docs/v3.3/dev-guide/api_reference_v3/
DCAE-1OOF interfaces with DCAE to fetch the current capacity of the Slice and slice subnets for NSI/NSSI selection NSI/NSSI Selection based on resource occupancy levels - DCAE changes


3. Component Description:

ONAP Optimization Framework (OOF) is an Umbrella project, with the primary goal of addressing the optimization needs of ONAP. OOF is a framework that supports creating and running a suite of Optimizing applications including: 

  • Homing/Placement optimizer
  • PCI optimizer
  • Route optimizer
  • Slice selection

OOF is targeted to be an optimization platform with the following goals: 

  • Declarative, policy-driven approach to solving optimization problems
  • Reusable components: data and policy adapters/libraries, execution environment
  • Support General-Purpose as well as Custom optimizers
  • Extensible to multiple optimization problems

Internally, OOF has the following components: 

  • OSDF: Optimization Service Design Framework, which is a collection of APIs and libraries, along with a generic runtime optimizer
    • Status: Part of ONAP since Beijing Release.
  • HAS: Homing and Allocation Service, which provides a policy based constraint driven selection optimizer
    • Status: Part of ONAP since Beijing Release.

4. Known system limitations

Please find the known system limitations in the following links

5. Used Models

OOF doesn't directly create models, but indirectly consumes them via AAI, Policy and Multi Cloud. 

  • Service and Resource Info, from: AAI
  • HPA Flavors/Capabilities/CapacityInfo, from : AAI
  • Policy Models (homing, PCI) from: Policy
  • Infrastructure Metrics Info (capacity), from: MultiCloud
  • Cloud agnostic Intent Info, from: MultiCloud
  • PCI configuration data (not yet part of SDNC model)
  • Slice/Subnet Profile and Slice/Subnet Instance models, from AAI

6. System Deployment Architecture

7. New Capabilities in this Release

  • AAF based authentication and removal of AAF-SMS dependency
  • Enhance NSI/NSSI selection to select NSI/NSSIs based on the current occupancy levels of the network
  • Integrate Generic Optimization Engine into OOF Helm charts (refer OOFE-5)

8. References


  • No labels