SNIRO Optimization Framework (5/11/17)

Project Name:

• Proposed name for the project: SNIRO (Optimization Framework)
• Proposed name for the repository: sniro

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.

When using the SNIRO framework, service designers and operators create policies. SNIRO gathers information from these policies and data sources related to a problem; translates that into constraints for optimization problems; and solves them using reusable optimization capabilities. This policy- and model-driven approach promotes efficient reuse of optimization functions. Thus, one of the main objectives of SNIRO is to provide a unified approach to eliminate code redundancy and to reduce overhead associated with managing different optimization applications.

Initial use cases for SNIRO: 

1. Placement of VNFs (homing).
2. Change management scheduling (providing schedule of changes for upgrading of VNFs under given constraints).
3. Effective allocation of licenses from pool of licenses in a geographically varied context

Examples of other intended use cases:

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.

2. Change Management Schedule Planning Use Case

Change Management (CM) application is responsible for managing and enforcing changes (e.g. device upgrade, configuration change, etc.) in the cloud and network infrastructure. Currently, a major part of CM scheduling is performed manually, which is time consuming, inefficient, and prone to service impacting errors. The schedule planning application provides recommended schedules of changes for upgrading of VNFs under given constraints and current state of schedules and relationships of network elements. The primary challenge is when to schedule changes such that service disruption is minimized. SNIRO offers a schedule optimization service to the CM application, which can be invoked prior to schedule any change. A service designer designs a change request in SDC and configures the schedule requirements through policies. Prior to scheduling changes via Service Orchestrator (SO), the designer makes a call to the schedule optimization in SNIRO from SDC. SNIRO collects the existing scheduling information from available ticketing system and vertical dependency information from A&AI and calculates a solution to the scheduling application. Finally, the recommended schedule is returned to SDC, which is verified by the designer before committing the schedules to Service Orchestrator.

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

Repo name:
Lifecycle State:
Primary Contact: Sastry Isukapalli
Project Lead: Sastry Isukapalli
mailing list tag [Should match Jira Project Prefix]: 

Committers:

Sastry Isukapalli sastry@research.att.com AT&T
Ankitkumar Patel ankit@research.att.com AT&T
Matti Hiltunen hiltunen@att.com AT&T
Shankar Narayanan snarayanan@research.att.com AT&T
Joe D'Andrea jdandrea@research.att.com AT&T
Maopeng Zhang zhang.maopeng1@zte.com.cn ZTE
Alexander Vul alex.vul@intel.com Intel
Mark Volovic marc.volovic@amdocs.com Amdocs

Yoram Zini (yzini) yzini@cisco.com Cisco

Rúben Borralho ruben.borralho@celfinet.com Celfinet

*Link to TSC approval: 
Link to approval of additional submitters: