Orchestration and Controller Architecture Alignment Vimal Begwani AT&T

Slides:



Advertisements
Similar presentations
BoF: Open NFV Orchestration using Tacker
Advertisements

Service Design & Onboarding
ONAP E2E Flow `.
Open-O SFC.Mgr Proposal
ONAP Management Requirements
ARC: Definitions and requirements for SO/APP-C/VF-C discussion including call notes Chris Donley July 5, 2017.
Microservice Powered Orchestration
Master Service Orchestrator (MSO)
ONAP and MEF LSO External API Framework Functional Reference Architecture 12 July 2017 Andy Mayer, Ph.D. © 2016 AT&T Intellectual Property. All rights.
Rationalizing ONAP Architecture for R2 and Beyond Vimal Begwani – AT&T
Open Network Automation Platform (ONAP) Controller Architecture Proposal DRAFT.
ONAP layering/MEF alignment
ONAP Architecture Meeting 8/8
Enterprise vCPE September 27, 2017.
Service Assurance in the Age of Virtualization
Multi-VIM/Cloud High Level Architecture
Orchestration and Controller Alignment for ONAP Release 1
ONAP Architecture Slides Current Plan of Record
ONAP Multi-VIM/Cloud Long Term Architecture and Use Cases (Under Community Discussion across Use Case, Optimization Framework, OOM,
Aligning Orchestration and Controller Per Merger Agreement Vimal Begwani – AT&T Jamil Chawki – Orange Alla Goldner -- Amdocs.
Multi-VIM/Cloud High Level Architecture
Tina Tsou, Bryan Sullivan,
Aligning Orchestration and Controller Per Merger Agreement Vimal Begwani – AT&T Jamil Chawki – Orange Alla Goldner -- Amdocs.
Rationalizing ONAP Architecture for R2 and Beyond
Interface to External Controllers and SD-WAN Use Case
ONAP and SD-WAN Integration Proposal
ONAP Interface to External Controllers
ARC: Definitions and requirements for SO/APP-C/VF-C discussion Chris Donley Date , 2017.
ONAP Architecture Meeting 8/8
OPEN-O Modeling Directions (DRAFT 0)
Agenda Overview High Level Architecture Design time Architecture
ARC 5: Deployment Options Chris Donley
ONAP Architecture Slides Current Plan of Record
MEF LSO Legato SDK 24 October 2017 Andy Mayer, Ph.D. Tara Cummings.
Target ONAP End-to-End Architecture Vimal Begwani – AT&T Parviz Yegani – Futurewei Technologies Jamil Chawki – Orange.
ONAP Integration to External Domain Management Systems (DMS)
Multi-VIM/Cloud High Level Architecture
17 Dec 2015 Bryan Sullivan, AT&T
ONAP Optimization Framework - HAS Shankar Narayanan - AT&T Labs Research 08/15/2017.
Enterprise vCPE use case requirement
ONAP Run-time Catalog Project
Target ONAP End-to-End Architecture Tiger Team Presentation Parviz Yegani – Futurewei Technologies Contributors: Vimal Begwani (AT&T), Jamil Chawki.
ONAP Reference Architecture for R2 and Beyond Tiger Team Presentation Parviz Yegani – Futurewei Technologies Contributors: Vimal Begwani (AT&T), Jamil.
ONAP Amsterdam Architecture
ONAP – Centralised Parser Distribution Atul Purohit - Vodafone
Enhanced Platform Awareness (EPA) Alex Vul Intel Corporation
VF-C R2 Feature Planning & Implementation Yan Yang
Agenda Where we are (Amsterdam Architecture)
ONAP APIs Andrew Mayer, AT&T
Open Source Access Manager™ ONAP Proposal
ONAP Amsterdam Architecture
Casablanca Platform Enhancements to Support 5G Use Case (Network Deployment, Slicing, Network Optimization and Automation Framework) 5G Use Case Team.
Casablanca Platform Enhancements to Support 5G Use Case Architecture Review 5G Use Case Team June 26, 2018.
Documenting ONAP components (functional)
Multi-VIM/Cloud High Level Architecture
20409A 7: Installing and Configuring System Center 2012 R2 Virtual Machine Manager Module 7 Installing and Configuring System Center 2012 R2 Virtual.
Management and Orchestration in Complex and Dynamic Environment
FUNCTIONAL Architecture for R2+
ONAP Beijing Architecture Chris Donley 1/9/18
Casablanca Platform Enhancements to Support 5G Use Case (Network Deployment, Slicing, Network Optimization and Automation Framework) 5G Use Case Team.
Defining ONAP VNF Package Model
ONAP Architecture for Rel 1
ONAP 5G USE CASE ENHANCEMENTS FOR PNF DEPLOYMENTS
Casablanca Platform Enhancements to Support 5G Use Case (Network Deployment, Slicing, Network Optimization and Automation Framework) 5G Use Case Team.
5G RAN Deployment – Casablanca PNF software and configuration management Huawei,
5G Use Case Configuration & PNF SW Upgrade using NETCONF ONAP DDF, Jan 9, 2019 Ericsson.
GNFC Architecture and Interfaces
ONAP Optimization Framework (OOF) POC for Physical CellID (PCI) Optimization July 30, 2018.
Proposed Approach for ONAP Runtime Support of Network Service Onboarding Gil Bullard, AT&T.
Title: Robust ONAP Platform Controller for LCM in a Distributed Edge Environment (In Progress) Source: ONAP Architecture Task Force on Edge Automation.
Presentation transcript:

Orchestration and Controller Architecture Alignment Vimal Begwani AT&T

High-level Architecture Guidelines: Clearly Articulate and Agree on Role of Service Orchestrator (SO) vs. Controller(s) Orchestration is stateless and performs transient tasks/functions, such as: Calls location optimization function to identify best data center placement for the VNF or service Queries inventory (A&AI) to determine resource availability Calls external license manager to get a valid license to create a new instance of the VNF or service Requests Infrastructure via multi-VIM layer to allocate right compute / memory / storage resources and instantiate the VNF/VNF components (one or more VM’s or one or more containers) Functions which are common across various controllers and can be aggregated should be consolidated into common layer (i.e. SO) Coordinates activities between various controllers (Infrastructure, Network, VNF, RAN Controllers)  Calls service assurance functions (DCAE) to deploy, configure and activate lifecycle management functions (analytics, data collectors, etc.) Controllers Maintain Topology, Configuration State, Perform Configuration Management and Provide Life Cycle Management Functions (i.e. common verbs – Restart, Suspend, Drain, etc.) Controller must support rich south bound adaption layers – Yang, Netconf, Chef, Ansible, vendor EMS (Ve-Vnfm-em), CLI, vendor VNFM (Ve-Vnfm-vnf), etc. Update A&AI with right topology information for newly deployed VNFs and Services When Possible, Leverage a Common Technology Across Various Controllers (Layer 1-3, Layer 4-7, RAN controllers, etc.). Reduces Overlaps, Enhancements / Changes Shared Across All Controllers, Simplifies Deployment Drive toward a “Controller Framework” for “Plug-&-Play” controller solutions and transactional roles. Enable controller identities to be defined through roles and requests rather than being predetermined at deployment, enabled by common libraries Support more efficient technology swap-out Key considerations and principles. Avoid same functionality replicated across various modules. Role of each module should be clearly defined and consistently followed. Aside from performing stateless/transient tasks, Orchestration functional role crosses domains and delegates. Controllers, on the other hand, are domain owners and active in lifecycle management

Release 1 Architecture: Option 1 Align Open-O’s NFV-O & ECOMP MSO into an integrated Orchestrator (SO) Enhance / Expand Controller Adaptor layer to meet broad SP requirements Expand VIM layer to support multiple cloud infrastructures Multiple instances of modules within green dotted lines can be deployed to support scaling and geographic distribution External API Gateway ONAP Portal Service Orchestrator (Integrated MSO & NFV-O) Active & Available Inventory SDC Service Workflow Design Data Collection & Analytics DMaaP / API Gateway Resource Workflow Design Policy Creation Multi-VIM Infrastructure Interface Open Stack AWS Infra. Adaption Layer Azure … SDN-C App-C Analytic Application Creation Config Database Config Database Service Logic Interpreter Service Logic Interpreter Recipie/ Engineering Rules & Policy Distribution Adaption Layer Adaption Layer Netconf Adaptor Yang Adaptor 3rd Party Adaptor Cont CLI Adaptor Netconf Adaptor Chef Adaptor ETSI Comp Adaptor EMS Adaptor(s) Vnfm Adaptor(s) Catalog Infrastructure Controllers EMS s-vnfm VNF 1 VNF 2 VNF 3 VNF 4 VNF 5 VNF 6 VNF 7 VNF 7

Sample VNF Instantiation Flow with Option 1: When a service Request is received by External API gateway, depending on the geographic region desired, requested is directed to right Service Orchestrator instance Service Orchestration performs the following steps (as described in the workflow recipe created in SDC), SO invokes location optimization to identify best data center placement for the VNF SO calls external license manager to get a valid license to create a new instance of the VNF Call resource assignment API to get parameters like hostname, static IP addresses etc. if they did not come in from SDC recipe or external API SO requests Infrastructure / multi-VIM layer to allocate right compute / memory / storage resources and instantiate the VNF/VNF components (one or more VM’s or one or more containers) – (Go to Step 3) SO requests SDN-C to perform necessary network configuration (could be multiple calls for WAN connection, overlay networking, etc.) – (Go to Step 4) SO Requests APP-C to configure the newly created VNF – (Go to Step 5) SO broadcasts “VNF in service ready” so that DCAE controller can start monitoring by the right DCAE instance  Multi-VIM Infrastructure Interface calls the right infrastructure controller to get right compute / Storage / memory resource allocated and VM(s) are created. – (Go to Step 2e) SDN-C controller performs the following functions (could be multiple calls from SO) SDN-C performs overlay network configuration SDN-C performs required WAN network configuration SDN-C could call legacy or 3rd party controller for WAN configuration – (Go to Step 2f) App-C performs the following steps App-C uses right DG to perform necessary VNF configuration setting App-C uses right adaptor to push the configuration to VNF (Netconf, Chef, ETSI etc.) If vendor EMS interface is required, right EMS adaptor is used to push the configuration If vendor VNF manager is required, right vnfm adaptor is used to push the configuration– (Go to Step 2g)

Release 1 Architecture: Option 2 Same as option 1 but all the ETSI compliant adaptors have been put on a separate module. App-C will have a dispatcher to send configuration requests to ETSI compliant VNFS to VF-C External API Gateway ONAP Portal Service Orchestrator (Integrated MSO & NFV-O) Active & Available Inventory SDC Service Workflow Design Data Collection & Analytics DMaaP / API Gateway Resource Workflow Design Policy Creation Multi-VIM Infrastructure Interface Open Stack AWS Infra. Adaption Layer Azure … SDN-C App-C VF-C Dispatcher VF-C Analytic Application Creation Config Database Config Database Service Logic Interpreter Service Logic Interpreter ETSI Compliant Adaption Layer Recipie/ Engineering Rules & Policy Distribution Adaption Layer Adaption Layer ETSI Adaptor EMS Adaptor(s) Vnfm Adaptor(s) Netconf Adaptor other Adaptor Netconf Adaptor Yang Adaptor 3rd Party Cont. Adaptor CLI Adaptor Chef Adaptor Catalog Infrastructure Controllers EMS s-vnfm VNF 1 VNF 2 VNF 3 VNF 4 VNF 5 VNF 6 VNF 7 VNF 7

Sample VNF Instantiation Flow with Option 2: When a service Request is received by External API gateway, depending on the geographic region desired, requested is directed to right Service Orchestrator instance Service Orchestration performs the following steps (as described in the workflow recipe created in SDC), SO invokes location optimization to identify best data center placement for the VNF SO calls external license manager to get a valid license to create a new instance of the VNF Call resource assignment API to get parameters like hostname, static IP addresses etc. if they did not come in from SDC recipe or external API SO requests Infrastructure / multi-VIM layer to allocate right compute / memory / storage resources and instantiate the VNF/VNF components (one or more VM’s or one or more containers) – (Go to Step 3) SO requests SDN-C to perform necessary network configuration (could be multiple calls for WAN connection, overlay networking, etc.) – (Go to Step 4) SO Requests APP-C to configure the newly created VNF – (Go to Step 5) SO broadcasts “VNF in service ready” so that DCAE controller can start monitoring by the right DCAE instance  Multi-VIM Infrastructure Interface calls the right infrastructure controller to get right compute / Storage / memory resource allocated and VM(s) are created. – (Go to Step 2e) SDN-C controller performs the following functions (could be multiple calls from SO) SDN-C performs overlay network configuration SDN-C performs required WAN network configuration SDN-C could call legacy or 3rd party controller for WAN configuration – (Go to Step 2f) App-C performs the following steps App-C uses right DG to perform necessary VNF configuration setting App-C uses right adaptor to push the configuration to VNF (Netconf, Chef, ETSI etc.) If the VNF requires ETSI MANO compliant interface, APP-C dispatcher sends request to VF-C with parameters VF-C uses ETSI MANO compliant adaptor (directly, EMS, or s-vnfm) to push the configuration– (Go to Step 2g)

Release 1 Architecture: Option 3 Align Open-O’s NFV-O & ECOMP MSO into an integrated Orchestrator (SO) Enhance / Expand Controller Adaptor layer to meet broad SP requirements Expand VIM layer to support multiple cloud infrastructures Multiple instances of modules within green dotted lines can be deployed to support scaling and geographic distribution External API Gateway ONAP Portal Service Orchestrator (Integrated MSO & NFV-O) Active & Available Inventory SDC Service Workflow Design Data Collection & Analytics DMaaP / API Gateway Resource Workflow Design Policy Creation Multi-VIM Infrastructure Interface Open Stack AWS Infra. Adaption Layer Azure … SDN-C App-C Analytic Application Creation Config Database Config Database Service Logic Interpreter Service Logic Interpreter Recipie/ Engineering Rules & Policy Distribution Adaption Layer Adaption Layer Netconf Adaptor ETSI Comp Adaptor EMS Adaptor(s) Netconf Adaptor Yang Adaptor 3rd Party Adaptor Cont CLI Adaptor Chef Adaptor Catalog Infrastructure Controllers VNF 1 EMS s-vnfm VNF 2 VNF 3 VNF 4 VNF 7 VNF 8 VNF 5 VNF 6

Sample VNF Instantiation Flow with Option 3: When a service Request is received by External API gateway, depending on the geographic region desired, requested is directed to right Service Orchestrator instance Service Orchestration performs the following steps (as described in the workflow recipe created in SDC), If the vnf uses vendor VNF-M then pass all the details to vendor VNF Manager, (Go to Step 2g) SO invokes location optimization to identify best data center placement for the VNF SO calls external license manager to get a valid license to create a new instance of the VNF SO requests Infrastructure / multi-VIM layer to allocate right compute / memory / storage resources and instantiate the VNF/VNF components (one or more VM’s or one or more containers) – (Go to Step 3) SO requests SDN-C to perform necessary network configuration (could be multiple calls for WAN connection, overlay networking, etc.) – (Go to Step 4) SO Requests APP-C to configure the newly created VNF – (Go to Step 5) SO broadcasts “VNF in service ready” so that DCAE controller can start monitoring by the right DCAE instance  Multi-VIM Infrastructure Interface calls the right infrastructure controller to get right compute / Storage / memory resource allocated and VM(s) are created. – (Go to Step 2d) SDN-C controller performs the following functions (could be multiple calls from SO) calls resource assignment API in controller to get parameters like hostname, static IP addresses etc. if they did not come in from SDC recipe or external API SDN-C performs overlay network configuration SDN-C performs required WAN network configuration SDN-C could call legacy or 3rd party controller for WAN configuration – (Go to Step 2e) App-C performs the following steps App-C uses right DG to perform necessary VNF configuration setting App-C uses right adaptor to push the configuration to VNF (Netconf, Chef, ETSI etc.) If vendor EMS interface is required, right EMS adaptor is used to push the configuration

Characteristics of ONAP Controllers: ONAP Controllers (SDN-C, App-C, etc.) are based ODL. ODL Provides a Industry Leading Controller Framework Platform robustness and maturity – ODL thru 6 releases has achieved a certain level of maturity.  It has a large community: 2k+ contributors; 5k+ members.  This will help speed up the hardening of the platform.  Numerous implemented projects that can be leveraged – BGP, PCEP, BGPMon, LACP, openstack plugins, OVSDB, SNMP, Openflow, etc.) Multi-protocol support both at network and cloud areas – netconf, yang, openstack Micro-service environment – ODL’s Karaf/OSGi environment enables a consistent environment for service logic, algorithms, analytics, and other functions to be developed, reused, and ported. MD-SAL supports modeling of functions and plugins into services (e.g., service function chaining) that northbound clients can consume.  It also enables SB adapters to be developed in a consistent fashion.  More importantly, it shields the northbound services from the complexity and changes in the SB layer.  ONAP controller framework includes service logic interpreter that work on independently developed and dynamically modified directed graphs.  This provides high level of flexibility for various stake holders to quickly developed DGs to support lifecycle management (e.g. configuration management, software upgrade, health check, diagnosis, etc.).