Project Name:

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


Subrepositories:
optf/has                     -- homing and allocation service

optf/cmso                  -- change management scheduling service

optf/osdf                    -- optimization service design framework

Project description:

ONAP needs core platform optimization services such as VNF placement and resource allocation (homing), and change management scheduling to function in any multi-site, multi-VIM, and multi-service environment. It could also benefit from a framework which promotes the reuse of software tools and algorithms to allow users to construct new optimization services and to extend/enhance existing platform optimization services.

This project currently provides the following two core platform optimization services, which are built to be service independent, policy driven, and extensible along with an optimization framework to enhance these or creating new services.

a) HAS (Homing and Allocation Service) optimizer: a policy driven service placement and resource allocation service to allow deployment of services and VNFs on a multi-site, multi-VIM infrastructure. This service performs function similar to classic OS schedulers or OpenStack scheduler. The role of the HAS is to select which cloud and which sites the elements of a service should be placed in, while respecting service constraints (latency, availability of specific platform features) as well as platform needs (cost).

b) CMSO (Change management scheduling optimizer): a policy driven workflow schedule optimizer for change management planning. The CMSO helps schedule workflows in time to maximize parallel change management activities, while respecting dependency between the workflows.

This will be delivered as three modules. One for HAS, one for CMSO, and one for the service design framework. The HAS and CMSO can execute both as services on DCAE and independent processes.

The set of platform optimization services will grow over time as the ONAP platform needs arise, and the optimization framework is envisioned to handle this as effectively as possible, with minimal or little new code development for creating new services. The optimization service design framework (OSDF), which can be used to build new optimization applications for users of ONAP, as well as to build new platform optimization services or extend the existing platform services through plugins. To demonstrate its capabilities, OSDF has been used to entirely build the change management scheduling optimizer (CMSO) as well as to build VNF license optimization and connectivity optimization plugins for the homing and allocation service (HAS). The OSDF is intended to allow future applications such as energy optimization in networks, optimal route selection, and radio access network (RAN) runtime performance optimization.

We will describe the current platform optimization services and optimization framework with their architectural fit one by one.

HAS: policy driven service homing and resource allocation on a multi-site, multi-VIM infrastructure. Homing/placement and allocation of resources is one of the fundamental requirements of provisioning a service over the cloud (or even non-cloud) infrastructure. HAS allows designers of services/VNFs to specify their service-specific placement requirements using policy constraints (e.g., geo-redundancy requirements for disaster recovery) and objective functions (e.g., minimize latency) linked to the service model. Then, at service deployment time, HAS collects information from AAI, DCAE, and other sources to determine a placement solution that meets service constraints while considering both the service objective function and the service provider preferences (e.g., cost) and constraints (e.g., available of capacity). Once a placement decision is made, a resource allocation (reservation) decision can be registered in AAI or with the resource manager for the resource if necessary. 

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

HAS will be designed to be used as a building block for both initial deployment, as well as runtime redeployment due to failures or runtime-capacity increase (scale-out). It will be designed to be usable for all platform placement functions, including placements of VMs, containers (e.g., for DCAE micro-services), or VNF specific resources. A plugin model will be provided to allow placements of additional resource types such as licenses, VNF resources. Plugin models will also allow extension by adding new constraint types, optimizer types, and objective functions.

Architecture alignment:

  • SO invokes HAS to get a placement and license allocation decision when deploying a new service, or when it is called to redeploy a service upon site failure, or upon increasing the capacity of an already existing service. This is particularly useful in multi-site or multi-VIM environments.
  • VF-C/App-C may need to invoke HAS to get a placement decision if an existing VNF must be rebuilt due to failure or increase in capacity.
  • OOM may need to invoke HAS to get a placement decision when deploying ONAP components e.g., to get a DCAE micro-service to be placed in proximity to the VNF it is monitoring.
  • Policy may need to support HAS by storing placement policies and associating them with service models
  • HAS uses information stored in AAI (e.g., available inventory), DCAE (e.g., performance, utilization), SDN-C and other ONAP components to make placement decisions.
  • Multi-VIM: HAS allows placement constraints to be specified that drives workloads to different cloud providers when appropriate (e.g., VNF requires some specific cloud platform) or desired (e.g., VNF requires certain level of reliability or performance that only some cloud providers can meet).

CMSO: VNF change management scheduling optimizer: 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. CMSO 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. OF offers the CMSO service to the CM application, which can be invoked prior to any change are scheduled. 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 CMSO from SDC. CMSO collects the existing scheduling information from available ticketing system and vertical dependency information from AAI 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 SO.

Architecture alignment:

  • AAI (e.g. network topology, cloud sites, service instances, scheduling/ticketing data)
  • DCAE (e.g. cloud-level resource utilization)
  • SDC (e.g. available VNF license artifacts)
  • Policy Service (e.g. rules/constraints

Optimization Service Design Framework. It a set of design time optimization libraries,  tools and microservices (MS) to facilitate and simplify the creation of new specific runtime optimization functionalities. The goal of this framework is to avoid siloed optimization tools and associated duplicated efforts and overheads. Indeed, the current platform services HAS  and CMSO use the framework extensively in their own development. Other potential optimization services that can be built using this framework include energy optimization in networks, optimal route selection for various network services, and radio access network (RAN) performance optimization.  The figure below illustrates the concept.

 



Architecture alignment:

• How does this framework fit into the rest of the ONAP Architecture?

  • Offers a set of MS which provide reusable optimization functionality which can optionally be used by other ONAP components if required by a use case
  • Provides a framework for building optimization services as a part of the ONAP ecosystem
  • Provides adapters to other ONAP systems (e.g. policy, AAI, 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

• What other ONAP projects does this project depend on?

  • AAI (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 VNF license artifacts)
  • Policy Service (e.g. rules/constraints)

• How does this align with external standards/specifications?

            N/A

• Are there dependencies with other open source projects?

  • Open source optimization solvers (e.g. GLPK/CBC, OR-Tools, optaplanner – 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

Resources:

  • Primary Contact Person
    • Sarat Puthenpura - AT&T
  • Names, gerrit IDs, and company affiliations of the committers
  • Names and affiliations of any other contributor
    • Ankit Patel - AT&T
    • Avteet Chayal - AT&T
    • Matti Hiltunen - AT&T
    • Joe D'Andrea - AT&T
    • Rúben Borralho - Celfinet
    • Mark Volovic - Amdocs
    • Manoj K Nair - Netcracker manoj.k.nair@netcracker.com
    • Alexander Vul - Intel
    • Rakesh Sinha - AT&T
    • Max Zhang - AT&T
    • Carlos De Andrade - AT&T
    • Kevin Smokowski - AT&T
    • Ramki Krishnan - VMware
    • Gil Hellmann - Wind River
    • Ikram Ikramullah - AT&T
    • Dileep Ranganathan - Intel
    • Gueyoung Jung - AT&T
  • 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:

Repo name: optf
Lifecycle State:
Primary Contact: Sarat Puthenpura (sarat@research.att.com)
Project Lead: Sarat Puthenpura
mailing list tag [Should match Jira Project Prefix]: 

Committers:

Sarat Puthenpura sarat@research.att.com AT&T
Sastry Isukapalli sastry@research.att.com AT&T
Shankaranarayanan Puzhavakath Narayanan - snarayanan@research.att.com AT&T
Maopeng Zhang zhang.maopeng1@zte.com.cn ZTE
Alexander Vul alex.vul@intel.com Intel
Yoram Zini (yzini) yzini@cisco.com Cisco

Vladimir Yanover mailto:vyanover@cisco.com Cisco


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


  • No labels

14 Comments

  1. Kaustubh Joshi pointed out that the name SNIRO does not capture the "Allocation" aspect (resource allocation) that is essential for homing/rehoming. That's why he proposed a new name "RAO" (resource allocation and optimization").

  2. SNIRO stands for Service, Network, Infrastructure, and Resource Optimizations. Thus, the resource optimization aspects are very well captured in the name. The framework is aimed to support a library of optimization applications in various domains such as networking, service, infrastructure, scheduling, etc.

  3. Would optaplanner be potentially useful here (http://www.optaplanner.org/) ? Here's a pointer to a demo that has some relevance on the domain under discussion here: http://www.optaplanner.org/learn/useCases/cloudOptimization.html

  4. Yes Pasi, thanks. Optaplanner is a fairly sophisticated solver and Ankit has had prior experience with it. We added optaplanner also as an example of a pluggable OSS solver.

  5. One query related to the Opta Planner. In Ankit's presentation, there was mention of using EMF model for creating the Optimization template. So assuming we fill this template during the design time, will this auto generate policy configuration (XACML) to be populated in policy framework? There was also a mention of constraint logic to be provided to the Solver - Is this a custom algorithm we need to implement for each use case ? 

  6. Manoj: Optimization constraints can be modeled using EMF. The goal is to auto-upload the these models into in the policy platform. The policy platform can next auto-generate policy templates which can be used by a service designer or operator to define optimization policies.

    Answering the second question: The vision is to provide a set of libraries using which an application designer can build the logic of translating policies into solver constraints with minimum efforts.

  7. Thanks Ankit, I have a follow up question . Is Optimization Framework meant to limit the capability to optimization decisions or is it planned to be extended to a full fledged planning solution . I feel Optimization framework has basic ingredients to be planning tool except the prediction capability . Is this also considered within the scope of SNIRO ? If yes, can you please give more details. 

  8. Hi All,

    Below are suggestions for other global friendly meeting times based on our discussions last week.

    Monday - 8:00am PT

    Friday - 7:00am PT or 8:00am PT

    Thanks,

    Ramki

  9. Our weekly meetings being moved from the current Tuesdays 9.00 am - 10.00 am (EDT) to Mondays 11.00 am - 12.00 noon (EDT) slot.

    Thx

    Sarat


  10. Few more  use cases - not sure if they come under the purview of Optimization framework. 

    • VNF Placement in Service Chain : For example a service chain can be constructed based on the VNFFG modelled at the NS level and then pushed down through the VIM/SDNC as port pair. One possibility might be to rely on a service function path constructed by the SDNC based on constraints such as latency, number of existing paths etc.But this will be restricted to a network-state based constraint.  Other possibility might be that Optimization framework giving inputs through solvers to SO or SDNC to create a service function path based on constraints modelled . I guess this will require interaction not only with A&AI, but also with the SDNC. An associated case might be the VNF adjacency constraint - for example two VNFs can/cannot be placed adjacent to each other in the service chain due to security restrictions. 
    • Inter connection between Service Chains - Say a subscriber has 2 services connected through service chain, and he procures a third service, where can the third service be connected in the existing service chain - at the edges or between two services . 
  11. Manoj, 

    The use-cases you described seem very interesting and falls right into the scope of what we are planning for R2. This also seems very much related to the SO workflows that we discussed in our weekly meeting earlier this wee. Do you happen to have any documentation or workflow diagrams for these service chains? If so, kindly forward them to the group, so that we can understand this in more detail and try to hash out the placement objective and the constraints involved. Also, it would be wonderful if you could present your thoughts on this during our next weekly call. 

    Thanks! 

    1. Sankar, Thanks for clarification. No, I don't have any workflow diagrams prepared as of now.

    2. Shankar, Please let us know when the Optimization Framework meeting is scheduled next. We would like to present the above ideas. Please find the slides here . Appreciate your comments.

  12. Hi Manoj, 

    I suspect we had little participation today morning, owing to the Labor day holiday. However, we will continue to have our weekly meeting at our regular schedule - Mondays 11.00 am - 12.00 noon (EDT), where you could present the service chain use case to the group. Thank you so much for sending over the slide deck - I'll also upload it at the resources/discussion page, where we have all other documents we have been discussing thus far.