Aligning Orchestration and Controller Per Merger Agreement Vimal

Aligning Orchestration and Controller Per Merger Agreement Vimal Begwani – AT&T Jamil Chawki – Orange Alla Goldner -- Amdocs

Current View (Orchestration & Controller Focus): Service Decomposition (Service Resources) Homing Optimization License Management VF-C Service Decomposition (Service Resources) Establish Network Connectivity (VLAN / WAN – SDN-C) VNF Orchestration Loop Request Resource Allocation (via Multi-VIM) Request VNF Configuration (via App-C / SDN-C) Service Logic Interpreter Adaption Layer Chef Netconf VNF 1 Vendor Specific VNF Manager Adaption Layer Ansible VNF 2 Config Database Multi-VIM Interface Service Logic Interpreter Vendor A Vendor B Vendor A VNFM Vendor B VNFM Vendor A EMS Vendor B EMS … Infra. Adaption Layer Netconf Yang Open Stack CLI AWS Azure VNF 5 VNF 3 VNF 4 ECOMP Community 2 NFVO SDN-C VNF Lifecycle Mgmt Config Database VNF Orchestration (1 or more) Request Resource Allocation (via multi-VIM) Loop Orchestrator (SO) App-C Overlapping functionality with SO ONAP VNF 6 Open-O Community VNF 7 VNF 8

ECOMP / Open-O Alignment – Step 1, Merger Agreement Driven Orchestrator (SO) Service Orchestration Common Orchestration module with deployment flexibility to meet SP’s scalability distribution needs Resource Orchestration Service Decomposition (Service Resources) Homing Optimization, License Management Establish Network Connectivity (VLAN / WAN – SDN-C, etc. ) VNF Orchestration Request Resource Allocation (via Multi-VIM) Request VNF Configuration (via App-C / SDN-C / VF-C) Common Controller Framework based SVNFMs Adaptor module (e. g. SLI, MDSAL based adaption layer) VF-C App-C SDN-C VNF Lifecycle Mgmt Config Database Service Logic Interpreter Adaption Layer Chef VNF 1 Netconf VNF 2 Ansible Config Database Service Logic Interpreter Yang Multi-VIM Interface CLI Open Stack AWS Life Cycle Mgmt DGs Vendor B … Vendor A VNFM Vendor B VNFM Vendor A EMS Vendor B EMS VNF 3 VNF 4 VNF 5 ONAP 3 Azure Service Logic Interpreter Adaption Layer Vendor A Infra. Adaption Layer Netconf Config Database VNF 6 VNF 7 VNF 8

ECOMP / Open-O Alignment – Step 2 (Full Integration): Orchestrator (SO) Service Orchestration Common Orchestration module with deployment flexibility to meet SP’s scalability distribution needs Resource Orchestration Service Decomposition (Service Resources) Homing Optimization, License Management Establish Network Connectivity (VLAN / WAN – SDN-C) VNF Orchestration Request Resource Allocation (via Multi-VIM) Request VNF Configuration (via SDN-C / g. VNF-C) g. VNF-Controller ( merged App-C / VF-C) SDN-C L 0 -3 Network Controller Config Database Service Logic Interpreter Yang Life Cycle Mgmt DGs Infra. Adaption Layer Open Stack CLI AWS Azure Config Database Service Logic Interpreter Chef Ansible VNF 1 VNF 9 VNF 10 4 Integrated L 4 -7 Generic VNF Controller Multi-VIM Interface Adaption Layer Netconf Common Controller Framework based VNF & Service Controller VNF 2 Netconf Adaption Layer Vendor B Vendor A VNFM Vendor B VNFM Vendor A EMS Vendor B EMS VNF 7 VNF 3 ONAP Service Dependency manager Life Cycle Mgmt DGs VNF 8 VNF 4

Alignment with ECOMP / Open-O Merger Agreement: § Merger Condition 1: ü Rename “MSO” to “SO” ü Expand SO to support TOSCA declarative model o Step 1 SO accomplishes exactly this goal and meets the merger condition. Expands MSO to support TOSCA declarative model and provide deployment flexibility to support scalability and resiliency requirements for various service providers. § Merger Condition 2: ü Create a new Controller consistent with App-C, to interface with vendor provided VNF-Managers o Step 1 VF-C accomplishes exactly this goal. Create a new controller module using common controller framework (as it exists today) to interface with vendor specific VNF managers, as stipulated in merger agreement. § Other Observation: ü Our ultimate goal should be a fully integrated ONAP platform so that all user can draw full benefit from contribution coming from various participants. Step 2 accomplishes that. 5

ONAP Target Merged Architecture Service & Product Design Policy Creation & Validation Analytic Application Design Catalog Products Services Resources Policies Eng. Rules Analytics Recipe / Engineering Rules & Policy Distribution Run-time ONAP Operations Management (OOM) External Data Movement & APIs A&AI DCAE Orchestration (SO) Active / Available Analytic µServices Service Orchestration Entitlements Resource Orchestration Resource / Service Topology Common Service DMaa. P Multi-VIM Interface Infrastructure Adaption Layer Open Stack AWS Azure AAF CDAP Logging Policy Runtime Policy Execution Engine … Holmes Data Distribution Data Collection Layer Micro. Service Bus SDN-C g. VNF-Controller (prev. App-C) L 0 -3 Network Controller L 4 -7 Generic VNF Controller Config Service Logic Database Interpreter Life Cycle Mgmt DGs Adaption Layer Netconf rd Yang CLI 3 Party Network controller Service Dependency manager Config Database Service Logic Interpreter Life Cycle Mgmt func. Standard & s. VNFM Adaption Layer Chef Netconf Ansible Vendor A Vendor B s. VNFM VNF 1 Infrastructure 6 VNF 2 Open. Stack VNF n VMware Rack. Space PNF Azure VNF x. . . EMS Lab Integration & Certification VNF SDK Resource Onboarding Testing & Certification Modeling (specs & Utilities) Design-time (SDC) BSS ONAP Portal – Design Studio & Dashboard

Merger Agreement Slides

CMCC proposal – Overall Architecture 1. Proposed New Controller is intended for accommodating 3 GPP VNFs with vendor specific VNFM/EMS. 2. VNF-C is expected to be compliant to the overall ECOMP architecture as much as possible. 3. VNF-C will also adapt to the MSB and internal APIs for interacting with other modules (including A & AI and DCAE, etc. ) 8

CMCC proposal – VNF Controller 9

Backup Slides

Terminology: § Functions – These are basic building blocks. Example of functions are: ü ü ü ü Resource Data Definition Management Workflows creation Service Decomposition (Service Resources) VNF Orchestration Requesting Infrastructure Resources Data Collection Analytics & Anomaly detection Etc. etc. § Modules – Logically relevant functions are grouped together and implemented as modules within ONAP. Example modules are ü SDC, A&AI, SO, App-C, DCAE, VF-C, Multi-VIM, SDN-C, etc. ü Each module as a well defined role and support set of functions. Overlaps between modules should be avoided. § Tasks – Allows user to accomplish certain results. One or more modules participate to complete a task ü ü 11 Onboard a resource, define management workflow Instantiate a VNF or Service (could use multiple VNFs) Closed loop automatic action Software Upgrade / Change Management

Descriptions of Example Modules: § OS Module is stateless and performs transient tasks/functions, such as: ü Service Decomposition (Service Resources) ü VNF Orchestration ü Functions which are common across various controller modules and are aggregated and consolidated into this common layer § § Location optimization function to identify best data center placement for the VNF or service Queries inventory (A&AI) to determine resource availability Calls to 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) ü Coordinates activities between various controllers (Infrastructure, Network, VNF, RAN Controllers) ü Orchestrator can be organized hierarchically (or multi-tier), Service Orchestrator spawning one or more VNF or network orchestration threads ü Calls service assurance functions (DCAE) to deploy, configure and activate lifecycle management functions (analytics, data collectors, etc. ) ü Orchestrator is called to Instantiate / configure VNF / Service, Closed loop action (e. g. Scale Up/Don), Change management, terminate, etc. § App-C, SDN-C Controller Modules Maintain Topology, Configuration State, Perform Configuration Management and Provide Life Cycle Management Functions (i. e. common API – Restart, Suspend, Drain, Health. Check, etc. ), 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. ü Controllers maintains and enforces VNF cross dependencies ü 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 Operations/Deployment/Scaling, Consistent Artifact Designs ü 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 ü Controller actions are triggered by Orchestrator (e. g. Instantiate), DCAE / Policy (Closed Loop), or Control Plane Events (BGP messages) 12

Descriptions of Example Modules (Continued): § SDC Module: ü Onboard Resources ü Create Resource Models o o o Resource Data Definition Management Workflows Associated Policies o o Service Topology and Chaining of Resources Service Data Definition Management Workflows Associated Policies ü Create Service Model ü Distribute Models to Execution Production Environment DCAE A&AI Etc. § § § 13

General Approach for ONAP Architecture Evolution (Short & Long Term) § We have a starting architecture and an implementation with more than 6 million lines of code ü We are not starting from scratch ü Over time community can collectively agree on enhancements that adds value or provide some benefits ü This code has been in production for more than 2 ½ years, supporting a live network and any disruptive architecture change should be carefully evaluated § Short term architecture enhancement should be driven by merger agreement between Open. ECOMP & Open-O § In addition to merger agreement, ONAP community has agreed on architecture principles and those should guide ONAP architecture evolution § Relevance of MANO should be objectively evaluated: ü ETSI MANO scope is extremely limited (no design environment, No Data Collection, Correlation, Analytics, No Policy Driven Closed Loop, etc. ) 14