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

Compare with Current View Page History

« Previous Version 5 Next »

Project Name:

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

Project description:

  • The SNIRO project aims to provide a platform for addressing different optimization needs (optimization as a service). Legacy legacy optimization applications often involve duplication of solution process and data adapters, and often include information on constraints and objectives in the application. SNIRO aims to provide a unified approach to eliminate code redundancy and to reduce overhead associated with managing different optimization applications.
  • Homing is one of the applications of the SNIRO platform. The automated placement/scheduling/homing of virtual resources is a basic capability of cloud platforms (e.g., Nova/Cinder in OpenStack). Such homing capability is provided to ONAP by SNIRO (Service, Network, Infrastructure, and Resource Optimization). It allows 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.

    Initial use cases: 

    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

    Other intended use cases:

    1. Network routing optimization
    2. Network and cloud capacity planning

Scope:

  • The main goals of SNIRO are to:

    1. Provide a set of reusable micro-services (e.g., API, data access) that allows new optimizers to be implemented more easily and provides 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).
    2. The data access micro-service provides a framework for adding drivers for different external systems (e.g., A&AI, SDN, DCAE) with modules for different specific queries. The data access micro-service provides reusable capabilities such as authentication, re-transmission, caching, and logging.
    3. Provides a framework that provides scalability and high-availability for the micro-services.
    4. Provide 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. Provide 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. Provide a library for translation of policies to constraints for an optimization engine.
    7. Provide a resilient, scalable optimization framework for solving optimization/planning problems and constraint satisfaction problems.
    8. Provide a mechanism for interacting with ONAP-C (ONAP controller) 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. This is different 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 (placement, scheduling, network, license, and planning) as a service to other ONAP subsystems

    • Provides adapters to other ONAP systems for optimization application developers 

  • What other ONAP projects does this project depend on?
    • Project depends on A&AI (e.g. network topology, cloud sites, service instances), DCAE (e.g. cloud-level resource utilization, scheduling data), SDN-C (e.g. network utilization, available capacity in a VNF instance), SDC (e.g. license artifacts), Policy (e.g. constraints) 
  • How does this align with external standards/specifications?
    • REST and Data Bus interfaces (service agnostic)
    • Models specified in SDC format
  • Are there dependencies with other open source projects?
    • Open source optimization solvers (GLPK/CBC, OR-Tools, these are pluggable)
    • Python eco-system

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
  • 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@research.att.com
ankit@research.att.com
hiltunen@research.att.com

snarayanan@research.att.com

jdandrea@research.att.com


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

  • No labels