Orchestration and Controller Alignment for ONAP Release 1

Orchestration and Controller Alignment for ONAP Release 1

High-level Architecture Guidelines: § We should leverage what is already developed and agreed earlier before ONS for guidelines. § Just to clarify some of the thoughts, it is important that we focus on the following § Targeted at the merger of ECOMP and OPEN-O, also allow flexibility especially when we are at the early phase of merger. § An integral closed loop automation: A&AI status update, DCAE monitor, Policy based correction, etc. § Practical and available on time: Leverage and reuse the existing open source solution with as less effort as possible in enabling (the following requirements that we already agreed earlier) § § § Support integration with ETSI NFV compliant vendor components, including VNFs and VNFMs Support the requirements of complicated end-to-end service demonstration based on the Use cases Support the life cycle management operations of service/resource (including model parsing, resource management, instantiation, start, heal, scaling, stop and deletion). § Be Flexible and micro-serviced based when integration with 3 rd party components, avoiding bindings to a specific selection. 2

Characteristics of ONAP Controllers: § NOT all 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. ). 3

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 4 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 (including ETSI compliant v. EMS) interface is required, right EMS adaptor is used to push the configuration d. If vendor VNF manager is required, right vnfm (including ETSI compliant vnfm) adaptor is used to push the configuration–(Go to Step 2 g) 5

Release 1 Architecture: Option 2 1. Align Open-O’s GS-O & ECOMP MSO into an integrated Orchestrator (SO) 2. Introduce Open-O’s NFV-O and GVNFM into VF-C to enhance / Expand Controller Adaptor layer to meet broad SP requirements for ETSI compliance. External API Gateway ONAP Portal Service Orchestrator (Integrated MSO & GS-O) SDC 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 Adaption Layer Netconf Adaptor VNF 1 Config Database Service Logic Interpreter Adaption Layer Service Logic Interpreter 3 rd Party Yang Cont. Adaptor VNF 2 VF-C App-C SDN-C CLI Adaptor Netconf Adaptor VNF 3 Chef Adaptor other Adaptor VNF 4 VNF 5 6 NFV-O G-VNFM ETSI Vnfm EMS Adaptor(s) EMS VNF 6 s-vnfm VNF 7

Sample Service Instantiation Flow with Option 2 1) 2) 3) 4) 5) 6) 7 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), a. SO decompose TOSCA service descriptor into one or several service components (here the service component can be further delegated to VF-C or APP-C or SDN-C). b. SO triggers the creation and configuration of each service component identified If the service component requires VF-C i. SO calls VF-C for its creation and configuration (Go to Step 6) else if the service component requires APP-C i. SO invokes location optimization to identify best data center placement for the VNF (need further clarification of this functionality) ii. SO calls external license manager to get a valid license to create a new instance of the VNF (need further clarification of this functionality) iii. 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 (need further clarification of this functionality) ii. 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) iii. SO Requests APP-C to configure the newly created VNF – (Go to Step 5) d. SO requests SDN-C to perform service component (necessary network configuration) (could be multiple calls for WAN connection, overlay networking, etc. ) – (Go to Step 4) e. SO broadcasts “Service Component/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 2 b v. or 6 e) 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 e) 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. ) (Go to Step 2 d) c. If vendor EMS (including ETSI compliant v. EMS) interface is required, right EMS adaptor is used to push the configuration d. If vendor VNF manager is required, right vnfm (including ETSI compliant vnfm) adaptor is used to push the configuration–(Go to Step 2 g) VF-C performs the following steps a. Parser service component Descriptor and decompose it into one or several VNFs b. invokes location optimization to identify best data center placement for the VNFs (need further clarification of this functionality) c. calls external license manager to get a valid license to create a new instance of the VNF (need further clarification of this functionality) d. VF-C 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. VF-C uses ETSI MANO compliant adaptor (directly, EMS, or s-vnfm) to push VNF configuration– (Go to Step 2 d)

Backup