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

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

3. ECOMP / Open-O Alignment – Step 1, Merger Agreement Driven
Orchestrator (SO)
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)
Service
Orchestration
Common Orchestration module with deployment flexibility to meet SP’s scalability distribution needs
Resource
Orchestration
Common Controller Framework based S-VNFMs Adaptor module (e.g. SLI, MD-SAL based adaption layer)
VF-C
App-C
SDN-C
Config Database
Service Logic
Interpreter
Life Cycle Mgmt DGs
VNF Lifecycle Mgmt
Service Logic
Interpreter
Multi-VIM Interface
Config
Database
Config
Database
Service Logic Interpreter
Adaption Layer …
Vendor A
Vendor B
Infra. Adaption Layer
Adaption Layer
Adaption Layer
Open
Stack
AWS
Azure
Chef
Netconf
Ansible
Netconf
Yang
CLI
Vendor A VNFM
Vendor B VNFM
Vendor B EMS
Vendor A EMS
VNF 1
VNF 2
VNF 3
VNF 4
VNF 5
VNF 7
VNF 6
VNF 8
ONAP

4. ECOMP / Open-O Alignment – Step 2 (Full Integration):
Orchestrator (SO)
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 / gVNF-C)
Service
Orchestration
Common Orchestration module with deployment flexibility to meet SP’s scalability distribution needs
Resource
Orchestration
Common Controller Framework based VNF & Service Controller
gVNF-Controller ( merged App-C / VF-C)
SDN-C
L0-3 Network Controller
Integrated L4-7 Generic VNF Controller
Multi-VIM Interface
Config
Database
Service Logic
Interpreter
Life Cycle Mgmt DGs
Config Database
Service Logic
Interpreter
Life Cycle Mgmt DGs
Service Dependency manager
Infra. Adaption Layer
Adaption Layer
Adaption Layer
Open
Stack
AWS
Azure
Chef
Netconf
Ansible
Vendor A
Vendor B
Netconf
Yang
CLI
Vendor A VNFM
Vendor B VNFM
Vendor A EMS
Vendor B EMS
VNF 9
VNF 1
VNF 7
VNF 3
VNF 8
VNF 10
VNF 2
ONAP
VNF 4

5. Alignment with ECOMP / Open-O Merger Agreement:
Merger Condition 1:
Rename “MSO” to “SO”
Expand SO to support TOSCA declarative model
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
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.

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

7. Merger Agreement Slides

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

9. CMCC proposal – VNF Controller

10. Backup Slides

11. 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
Onboard a resource, define management workflow
Instantiate a VNF or Service (could use multiple VNFs)
Closed loop automatic action
Software Upgrade / Change Management

12. 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, HealthCheck, 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.).
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.
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
Controller actions are triggered by Orchestrator (e.g. Instantiate), DCAE / Policy (Closed Loop), or Control Plane Events (BGP messages)

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

14. 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 OpenECOMP & 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.)