OPEN-O is a Linux Foundation Collaborative Project focused on building an open source, carrier grade orchestration platform. The primary goal is to establish an open framework to orchestrate end-to-end composite services across legacy networks, along with emerging SDN and NFV Infrastructure. This document will explain the OPEN-O architecture at a functional level in a clear & concise manner. 

Management Layers

OPEN–O is positioned in the services layer to create and manage any service over any network. The below picture describes how various open source projects fit in different layers to deliver the e2e management and control functions. OPEN–O on the south bound interworks with different SDN controllers, NMS /EMS systems, VNFM and VIM’s to create end-to-end services.

Management Layers

Figure 1- Management Layers

OPEN-O Architecture Overview

The OPEN-O architecture is compliant with the ETSI NFV Architectural Framework and Management and Orchestration (MANO), and has adopted standard service modeling languages YANG and TOSCA to ensure commonality and flexibility. OPEN-O has three main Orchestration functions namely Global Services Orchestrator (GS-O), SDN Orchestrator (SDN-O) and Network Function Virtualization Orchestrator (NFV-O) supported by Orchestrator Common functions. The Orchestrator common provides TOSCA related micro services for GS-O, SDN-O and NFV-O and includes TOSCA Parser (Project ARIA), TOSCA Catalog, TOSCA Graphical Designer, and an Inventory.

OPEN-O Architecture

Figure 2 - OPEN-O Architecture

GS-O - Global Services Orchestrator

GS-O is responsible for Global Service Orchestration to provide End-to-End orchestration of any service on any network. GS-O allows the user to describe the end-to-end (global) service in a single Global Service Description. GS-O decomposes the Global Service Description to SDN Service Descriptions and NFV Service Descriptions, and then forwards these requests to the correct instances of SDN-O and NFV-O.

The main components of GS- O include Service life cycle manager, service decomposer, service parser and NBI layer. The NBI layer interworks with Business operations layer through which GS-O receives the information about the services it needs to create to fulfill the product requests from business layer. GS- O Performs the creation & activation of global service instance and deactivate & deletion of global service instance.

NFV-O - Network Functions Virtualization Orchestrator

This NFV-O function is based on ETSI NFV MANO architecture & information model as a reference. It orchestrates Network Services composed of Virtualized Network Functions and is an integral part of OPEN-O. The NFV-O function includes Network service life cycle manager, NFV resource manager, and NFV monitor. Using the south bound SBI, NFVO interworks with several NFV SDN controllers, Multi- vendor VNFM’s and different VIM’s.

The NS LCM (Network Service – Life Cycle Management) includes NS template design, NS package onboarding, NS instance creation, NS instance termination and NS package deletion. NS is composed of VNFs and the connections to be deployed. The LCM feature also includes a GUI portal that is used for NS template design (including workflow editing) and LCM operations.

The NFV-O also provides basic alarm monitoring and performance statistics of VIMs and Hosts.

NFV-O APIs/interfaces:

  • NBI: Interfaces between GS-O and NFV-O based on REST API;
  • SBI: Interfaces between NFV-O and drivers for (VNFM, SDNC, and VIM) on REST API;
  • Information Model and Data Models:
    • Candidates under consideration: ETSI NFV 1.0/2.0, TOSCA NFV Profile v004/005, YANG for SFC.

SDN-O – Software Defined Network Orchestrator

The SDN-O provides network service orchestration over SDN and Legacy networks. It will provide full service life-cycle functionality (design, provision, operate). Release 1 is focused on network integration and automated network provisioning. Future releases will address dynamic model driven service design, provisioning and assurance, as well as working with SDOs to align models and APIs.

SDN-O Features and Functionality:

  • Provisioning and activation of e2e network connectivity services.
  • Provisioning of both underlay (L3 VPN and L2 VPN) and overlay (VxLAN, IPSec, VPC, Service Chain) network connectivity
  • Basic Resource Inventory
  • Monitoring of utilization and optimization of the network path
  • SDN-O APIs and TOSCA templates
  • Simple SDN-O Portal
  • Common SBI for VxLAN, IPSec, L3VPN, L2VPN, VPC, Service Chain

Common Services

Provide the common services for all the other OPEN-O components, including Micro service Bus, HA, Driver Manager, Log, Authentication, External System Register and Protocol Stack.

Common service Features:

  • Service Registration – API, file, UI, Service Discovery, Service Call Routing, API Call Logging and Asynchronous Message Routing-Comet.
  • Micro service Bus Cluster, Load balancing for stateless service and Service healthy monitoring.
  • Provide User Management, login /logout and Session Management.
  • RESTCONF Protocol Stack : A REST like protocol running over HTTP for accessing data defined in YANG using datastores defined in NETCONF.
  • NETCONF Protocol Stack : The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. 

Common TOSCA

Common TOSCA provides shared components for designing, modeling, validating, executing and storage of VNFs, Network Services (NS) and Service Function Chaining (SFC) and related resources needed for GS-O, NFV-O and SDN-O.

Common TOSCA sub modules:

  • TOSCA Parser and execution engine(ARIA) with OpenStack VIM Plugin and NETCONF Plugin
  • Workflow Engine (ARIA)
  • Graphical Modeling Designer
  • Catalog
  • Inventory
  • Policy
  • Analytics

Common TOSCA Features:

  • Create service template and plan, Support layered/nested Service
  • Provide Catalog Features: CSAR upload, download, delete, query, status management.
  • Provide REST API interface to query information model.
  • Provide artifacts download (software pkg. , image, scripts, policy, plan, etc.)
  • Provide Inventory functions, as resources centralized storage function, schema less data stores, CURD (create, update, read, delete) REST interface for GS-O/SDN-O/NFV-O and Maintain the relationship of resource instance include the resources change notification.


  • Enable operators to capitalize on NFV and SDN architecture
  • Multi-domain, multi-location, and end-to-end service composition
  • Adopt industry-wide common information model and TOSCA/YANG (RFC 6020) data models to ensure extensibility, implementation efficiency, and interoperability
  • Provide a common platform for VNF vendors, simplifying and accelerating VNF onboarding, development, and deployment
  • Enhance the overall service lifecycle, through model-driven automation to enable reuse and incremental upgrades
  • Provide abstraction to operate over diverse SDN, NFV, and legacy network.