1. Orchestration and Controller Architecture Alignment Vimal Begwani AT&T

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

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

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

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

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

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

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

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