MANO Working Group
Page tree
Skip to end of metadata
Go to start of metadata

Subpages

This wiki is being organized into sub-pages for different focuses:

Current Discussions in MANO WG

The table below covers the main discussion themes and goals of the MANO WG, as it considers OPNFV aspects in its scope (see the Intro below for more description of that scope). Links to related pages/documents will be provided as they are developed.

GoalApproachNotes
Assess the various architectural approaches to MANO functions, e.g. across onap, OpenBaton, OSM, ...

On the Architecture page, provide links to documentation and assessment the the various approaches.

 
Assess the service/VNF lifecycle (e.g. sequence of operations) as supported by the various MANO projects.

Provide links to documentation and assessment the the various approaches in wiki pages, e.g.

  • the VNF Onboarding page, which addresses the broad outline of the VNF lifecycle with focus on the "onboarding" aspects
  • the Lifecycle page which addresses the sequence of operations for deployment, and lifecycle events (hooks) supported by the MANO project e.g. through generic or specific VNFMs.
 
Assess goals and options for MANO function integration into OPNFV.

On the Integrating MANO Components in OPNFV page, consider the options, e.g.:

  • inherent (pre-installed for all scenarios)
  • installable on-demand (install-time option or post-install)
  • installed for test purposes (e.g. as current for vIMS, and the Models project tests
 
Recommend ways in which we can promote convergence in the aspects above.  

 

Intro to OPNFV MANO (Management & Orchestration) Group

Current intro presentation: State of MANO in OPNFV.pptx

A group dedicated to improve MANO integration in OPNFV through evolving standards and open source software implementations that enriches the MANO Stack in OPNFV reference architecture. The idea here is to issue periodically advice and issue guidelines based on gap analysis between existing reference architectures in OPNFV for MANO and related standards(star), projects( (star))and upstream software(star) to be able promote OPNFV Platform and VNF interoperability, extensibility, configurability, security, portability and performance for VNF Life Cycle management, NFV Orchestration and VIM advancements.
Provide an 'umbrella' group to encourage development of MANO centric functions within the OPNFV eco-system.
Effectively handle NFVO & VNFM from different projects to integrate with VIM in a standard manner and help build VNF certification over OPNFV Platform working with C&C and Dovetail using MANO and other Testing tools.

3d View of OPNFV Platform MANO Interaction with End Users


OPNFV Platform MANO User Stories


Proposed Enhanced Reference Platform for MANO Integration in OPNFV

EMS - Element Management System - The Element Management System performs the typical management functionality for one or several VNFs.

MANO Front View  Diagram reflects only EMS / VNF used to deliver network/application service and any  MANO qualified project could be placed in relation to their function in reference architecture. e.g.

 

EMS1 - Fault Management for VNF1 - Managed by Doctor Project and its Vendor extension by Vendor say NEC ( DOCTOR + SFQM + OpenStack Congress)

 

EMS2 - Alert Management for  VNF2 - Managed by VNF Event Streaming (VES) and VEC and generic or Vendor add-on for VEC agent

 

EMS3 - Configuration Management for VNF3 - A Juju client and Server to support hooks for VNF3  functionality as a Charm

 

Note OSS/BSS supporting upstream software may implement Os-Ha (thorugh SDN-O) , Os-Ve (Generic or Vendor specific), Global Service Orchestrator driving Service Orchestrator, which in turn may interface with NFVO through API or through  CLI calls.

Some VNFs can also be considered as MANO candidates: eg. vForwarder (refer OPNFV NetReady).

This opens out new opportunity for MANO designated projects to  innovate up and above the VIM Stack.

We also see opportunity for Muti-VIM, Multi-NViPOPs, Multi-VNFM and Multi-NFVO. However not get into split brain issues we prefer to keep Global Service Orchestrator with either single or multiple Srevice Orchestraor ( or Drivers) as they may choose in their implementations like OPEN-O, OSM etc.

Two additional interfaces are in play So-Ca and Ca-Ma or Catalog management for Service as well VNF and Infrastructure. Note this may be indexes of offered or running instances and supported by various templates and descriptors based on TOSCA, YANG,UML and other hybrid DSLs or Linux Distro's specific models and hooks for their agents.

We would like some validations based on MANO qualified projects before zeroing on what works as common minimum across different efforts in OPNFV echo system.

Eventually a MANO marketplace will evolve and reach maturity to run through Compliance Validation Program(CVP) in Release D and later.


Key formation Facts

Group  Creation Date: OPNFV MANO work group Group Prefix: opnfv-mano

TSC#June21,2016

MANO working group discussion 

  • Establishing a working group to coordinate among projects relating to MANO.

 Members

 MANO team's mail alias:
                mano-wg@lists.opnfv.org
 To subscribe or un-ubscribe via the World Wide Web, visit:
                https://lists.opnfv.org/mailman/listinfo/mano-wg

 

ETSI Standards Public documents

MANO Related News/blogs



  • No labels