/
OOF Frankfurt (R6) Architecture Review

OOF Frankfurt (R6) Architecture Review

Owned by Shankaranarayanan Puzhavakath Narayanan
Last updated: May 31, 2020
3 min read

1. Project Overview

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: 
-Change Management Scheduling optimizer
-Homing/Placement optimizer
-PCI optimizer
-Route optimizer

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.

  • CMSO: Change Management Schedule Optimizer, providing schedule optimization

    • Status: Seed code up-streamed in R3

  • FGPS: Fine Grained Placement Service

    • Status: Seed code up-streamed, POC in Frankfurt

2. Functional enhancements for Frankfurt

The key functional enhancements planned for Frankfurt are as follows:  

  • Moving to new Policy APIs as a part of Component Upgrades to new Policy Lifecycle API

  • Support for E2E Network Slicing

  • Internal re-architecture to allow streamlined onboarding of new optimization use cases. 

  • CCVPN route optimization

3. Architecture Diagram (Functional view)

Internal re-architecture (follow up on ONAPARC-406: Dublin Architecture Review: OOFClosed)

Deployment architecture





4. New and modified interfaces

New interfaces

OOF provides the following interfaces:

Interface Name

Interface Definition

 Interface Capabilities

Interface Name

Interface Definition

 Interface Capabilities

OOFE-6

Network Slicing

This interface enables slice selection recommendations.  

OOFE-5

OOF Model Administrator

This 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.

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

The current API documents can be found at:

Unchanged interfaces

Interface Name

Interface Definition

 Interface Capabilities

Interface Name

Interface Definition

 Interface Capabilities

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. 

OOFE-2

PCI/ANR Optimization

Enables PCI/ANR optimization API for SON.

OOFE-3

Schedule Optimization

a policy driven workflow schedule optimizer for change management planning. This interface schedule workflows in time to maximize parallel change management activities, while respecting dependency between the workflows.

OOFE-4

Route Optimization

Provides an interface for Router Optimization.

Consumed interfaces

OOF consumes the following Interfaces:

Interface Name

Purpose Reason For Use

Interface Name

Purpose Reason For Use

SDCE-1

For PCI/ANR optimization, OOF Retrieves the Cellsite inventory details from the configdb API, which is hosted as part of the SDNC/R component

AAIE-1

OOF interfaces with AAI to retrieve the inventory

MCE-5

OOF queries Multicloud for real-time available capacity information

MUSICI-1

OOF interfaces with MUSIC to persist service state.



5.  System limits

Please find the known system limitations in the following links

6. Involved use cases, architectural capabilities or functional requirements

  • Usecases

    • Service/VNF instantiation

    • HPA

    • Change Management - Traffic Distribution

    • 5G / OOF SON 

    • 5G / Network Slicing

    • CCVPN

7. Platform Maturity Targets

Frankfurt Release Platform Maturity

In-addition, following SECCOM activities are being worked for Frankfurt

  • Address outstanding OJSI issues

  • Java 11 Upgrade for CMSO

  • Python 2.x EOL migration for OSDF, HAS, and FGPS

  • Following additional TSC "must-haves" will also be addressed in this release(OPTFRA-640: This epic addresses TSC Must-have S3P requirements for Frankfurt releaseClosed)

    • Document current upgrade component strategy

    • SECCOM Perform Software Composition Analysis - Vulnerability tables

    • SECCOM Password removal from OOM HELM charts

    • SECCOM HTTPS communication vs. HTTP