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