Orchestration and Controller Architecture Alignment Vimal Begwani ATT

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. ). o Reduces Overlaps, Enhancements / Changes Shared Across All Controllers, Simplifies Deployment ü Drive toward a “Controller Framework” for “Plug-&-Play” controller solutions and transactional roles. o Enable controller identities to be defined through roles and requests rather than being predetermined at deployment, enabled by common libraries o Support more efficient technology swap-out Key considerations and principles. § ü ü 2 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 External API Gateway ONAP Portal Service Orchestrator (Integrated MSO & NFV-O) SDC 1. Align Open-O’s NFV-O & ECOMP MSO into an integrated Orchestrator (SO) 2. Enhance / Expand Controller Adaptor layer to meet broad SP requirements 3. Expand VIM layer to support multiple cloud infrastructures 4. Multiple instances of modules within green dotted lines can be deployed to support scaling and geographic distribution Active & Available Inventory Service Workflow Design Resource Workflow Design Policy Creation Analytic Application Creation Recipie/ Engineering Rules & Policy Distribution Catalog Data Collection & Analytics DMaa. P / API Gateway Multi-VIM Infrastructure Interface Config Database Infra. Adaption Layer Open Stack AWS Azure … Infrastructure Controllers App-C SDN-C Service Logic Interpreter VNF 1 Yang Adaptor 3 rd Party Adaptor Cont VNF 2 CLI Adaptor VNF 3 Netconf Adaptor ETSI Comp Chef Adaptor VNF 4 VNF 5 3 Service Logic Interpreter Adaption Layer Netconf Adaptor Config Database EMS VNF 6 Vnfm EMS Adaptor(s) s-vnfm VNF 7

Sample VNF Instantiation Flow with Option 1: 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 2) Service Orchestration performs the following steps (as described in the workflow recipe created in SDC), a. SO invokes location optimization to identify best data center placement for the VNF b. SO calls external license manager to get a valid license to create a new instance of the VNF c. 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 d. 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) e. SO requests SDN-C to perform necessary network configuration (could be multiple calls for WAN connection, overlay networking, etc. ) – (Go to Step 4) f. SO Requests APP-C to configure the newly created VNF – (Go to Step 5) g. SO broadcasts “VNF in service ready” so that DCAE controller can start monitoring by the right DCAE instance 3) 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 2 e) 4) SDN-C controller performs the following functions (could be multiple calls from SO) a. SDN-C performs overlay network configuration b. SDN-C performs required WAN network configuration c. SDN-C could call legacy or 3 rd party controller for WAN configuration – (Go to Step 2 f) 5) App-C performs the following steps a. App-C uses right DG to perform necessary VNF configuration setting b. App-C uses right adaptor to push the configuration to VNF (Netconf, Chef, ETSI etc. ) c. If vendor EMS interface is required, right EMS adaptor is used to push the configuration d. If vendor VNF manager is required, right vnfm adaptor is used to push the configuration– (Go to Step 2 g) 4

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

Sample VNF Instantiation Flow with Option 2: 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 2) Service Orchestration performs the following steps (as described in the workflow recipe created in SDC), a. SO invokes location optimization to identify best data center placement for the VNF b. SO calls external license manager to get a valid license to create a new instance of the VNF c. 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 d. 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) e. SO requests SDN-C to perform necessary network configuration (could be multiple calls for WAN connection, overlay networking, etc. ) – (Go to Step 4) f. SO Requests APP-C to configure the newly created VNF – (Go to Step 5) g. SO broadcasts “VNF in service ready” so that DCAE controller can start monitoring by the right DCAE instance 3) 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 2 e) 4) SDN-C controller performs the following functions (could be multiple calls from SO) a. SDN-C performs overlay network configuration b. SDN-C performs required WAN network configuration c. SDN-C could call legacy or 3 rd party controller for WAN configuration – (Go to Step 2 f) 5) App-C performs the following steps a. App-C uses right DG to perform necessary VNF configuration setting b. App-C uses right adaptor to push the configuration to VNF (Netconf, Chef, ETSI etc. ) c. If the VNF requires ETSI MANO compliant interface, APP-C dispatcher sends request to VF-C with parameters d. VF-C uses ETSI MANO compliant adaptor (directly, EMS, or s-vnfm) to push the configuration– (Go to Step 2 g) 6

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

Sample VNF Instantiation Flow with Option 3: 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 2) Service Orchestration performs the following steps (as described in the workflow recipe created in SDC), a. If the vnf uses vendor VNF-M then pass all the details to vendor VNF Manager, (Go to Step 2 g) b. SO invokes location optimization to identify best data center placement for the VNF c. SO calls external license manager to get a valid license to create a new instance of the VNF d. 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) e. SO requests SDN-C to perform necessary network configuration (could be multiple calls for WAN connection, overlay networking, etc. ) – (Go to Step 4) f. SO Requests APP-C to configure the newly created VNF – (Go to Step 5) g. SO broadcasts “VNF in service ready” so that DCAE controller can start monitoring by the right DCAE instance 3) 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 2 d) 4) SDN-C controller performs the following functions (could be multiple calls from SO) a. 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 b. SDN-C performs overlay network configuration c. SDN-C performs required WAN network configuration d. SDN-C could call legacy or 3 rd party controller for WAN configuration – (Go to Step 2 e) 5) App-C performs the following steps a. App-C uses right DG to perform necessary VNF configuration setting b. App-C uses right adaptor to push the configuration to VNF (Netconf, Chef, ETSI etc. ) c. If vendor EMS interface is required, right EMS adaptor is used to push the configuration 8

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: 2 k+ contributors; 5 k+ 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. ). 9