Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Project Name:

  • Proposed name for the project: SNIRO (ONAP Optimization Framework (ONAP-OF)
  • Proposed name for the repository: sniro: optf


Subrepositories:


optf/pas                     -- placement and allocation service


optf/cmso                  -- change management scheduling service


optf/osdf                    -- optimization service design framework


Project description:

The SNIRO project (Service, Network, Infrastructure, and Resource Optimization) aims to provide a platform for addressing different optimization and resource allocation needs (optimization as a service). Legacy applications typically support specific business or network application needs, and are developed independently. When a carrier or service provider has a wide range of business and network applications, legacy approaches often result in siloed tools and duplicated efforts with associated development and operational overhead.

...

  1. Network routing optimization
  2. Self-Organizing Network (SON)
  3. Energy-optimized networks

Project Scope:

  • The main goals of SNIRO are to provide:

    1. a set of reusable micro-services (e.g., API, data access) that allows new optimizers to be implemented more easily;
    2. a standardized interface for optimizers to communicate with other optimizers (e.g., homing optimizer interacting with license optimizer to check a solution for any license related constraints);
    3. scalability and high-availability for the optimization micro-services and supporting micro-services;
    4. a unified toolkit for developing optimization applications via extensible APIs. This facilitates developing new optimization applications independent of how the underlying optimization modules are implemented;
    5. a library of optimization engines/solvers. This will include an API for plugging other custom entities (custom data sources; proprietary or open source optimization engines/solvers; etc.);
    6. a library for translation of policies to constraints for an optimization engine.
    7. (in longer term) a mechanism for interacting with the ONAP Operations Manager (OOM) to take actions based on the optimization solution.

    The term optimization here is used in the context of providing a solution (or set of solutions) for a problem specified in terms of the state (available resources, topology, objective, etc.) and additional constraints specified as a set of policies. It must be noted that This is different from the use of optimization in other contexts such as “performance optimization”, “platform stability/reliability”, “scalability”, etc.  While such services may need information from optimization solutions (e.g. “when should one take an action”, “how much additional capacity is needed to ensure meeting a specific SLA”), they can be considered as applications that can utilize the optimization framework.

Architecture Alignment:

  • How does this project fit into the rest of the ONAP Architecture?
    • Provides optimization (e.g. homing, scheduling, network, license allocation, and capacity planning) as a service to other ONAP subsystems

    • Provides adapters to other ONAP systems (e.g. policy, A&AI, SDC, etc.) for optimization application developers

    • Uses REST and Data Bus interfaces in a service agnostic manner
    • Models and artifacts are specified in SDC format, while rules/constraints are specified in Policy Service
    • The homing and license allocation applications are expected to support the Multi-VIM Project
    • The scheduling application (change management scheduling) is expected to support the Network Change Management Project
  • What other ONAP projects does this project depend on?
    • A&AI (e.g. network topology, cloud sites, service instances, scheduling/ticketing data)
    • DCAE (e.g. cloud-level resource utilization)
    • SDN-C (e.g. network utilization, available capacity in a VNF instance)
    • SDC (e.g. available license artifacts)
    • Policy Service (e.g. rules/constraints)
    • Policy-driven VNF Orchestration
  • How does this align with external standards/specifications?
  • Are there dependencies with other open source projects?
    • Open source optimization solvers (GLPK/CBC, OR-Tools, these are pluggable)
    • Python eco-system (modules for schema validation, database adapters, etc.)
    • While the code is primarily written in Python, we anticipate it to be a mixture of Java and Python

Use case Description:

1. Homing Use Case

The homing of resources is one of the fundamental requirements of provisioning a service over the cloud or non-cloud infrastructure. The Homing application allows designers of services/VNFs to specify their homing requirements (either in the Policy Service linked to the service model or directly in the TOSCA service model) and objective function (e.g., minimize latency). Then, at service deployment time, SNIRO collects information from A&AI, DCAE, and other sources to determine a homing solution that meets service constraints while considering both the service objective function and the service provider preferences (e.g., cost). SNIRO can home a request either to a cloud site where new virtual resources are to be created or to an existing service instance. When the services deployed become more complex (e.g., multiple VNFs with different constraints for individual VNFs and the combinations of VNFs) and the cloud infrastructure is large (e.g., dozens or more possible sites), such capability is essential for managing the services and the infrastructure.

...

Effective allocation of licenses to services is often complex because the costs depend on factors such the specifications of VNFs and provider-vendor agreements. Often, license agreements may involve many factors such as license agreement validity, geographically diverse location requirements, VNF operational characteristics, etc. Prior to assigning a license, a Service Orchestrator (SO) or a related portal consults SNIRO for the selection of a license group. SNIRO retrieves license selection criteria from policy platform as policies from the policy platform. Next, the license allocation application retrieves license models from SDC and selects license groups that meets the criteria, and then returns a solution to SO.

Resources:

  • Primary Contact Person
    • Sastry Isukapalli - AT&T
  • Names, gerrit IDs, and company affiliations of the committers
    • Sastry Isukapalli - AT&T
    • Ankit Patel - AT&T
    • Matti Hiltunen - AT&T
    • Shankar Naraynan - AT&T
    • Joe D'Andrea - AT&T
    • Maopeng Zhang - ZTE
    • Alexander Vul - Intel
    • Mark Volovic - Amdocs
  • Names and affiliations of any other contributors
  • Project Roles (include RACI chart, if applicable)

Other Information:

  • link to seed code (if applicable)
  • Vendor Neutral
    • if the proposal is coming from an existing proprietary codebase, have you ensured that all proprietary trademarks, logos, product names, etc., have been removed?
  • Meets Board policy (including IPR)

Use the above information to create a key project facts section on your project page

Key Project Facts

Project Name:

  • JIRA project name: SNIRO (Optimization Framework)
  • JIRA project prefix: sniro-open-of

...