1. Orchestration and Controller Alignment for ONAP Release 1

2. 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 3rd party components, avoiding bindings to a specific selection.

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

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

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

6. Release 1 Architecture: Option 2
Align Open-O’s GS-O & ECOMP MSO into an integrated Orchestrator (SO)
Introduce Open-O’s NFV-O and G-VNFM 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)
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
Analytic Application Creation
Config
Database
Config
Database
Service Logic Interpreter
Service Logic Interpreter
NFV-O
G-VNFM
Recipie/
Engineering Rules & Policy Distribution
Adaption Layer
Adaption Layer
ETSI
Adaptor
EMS
Adaptor(s)
Vnfm
Adaptor(s)
Netconf
Adaptor
other
Adaptor
Chef
Adaptor
Netconf
Adaptor
Yang
Adaptor
3rd Party
Cont. Adaptor
CLI
Adaptor
Catalog
Infrastructure Controllers
EMS
s-vnfm
VNF 1
VNF 2
VNF 3
VNF 4
VNF 5
VNF 6
VNF 7
VNF 7

7. Sample Service 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 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).
SO triggers the creation and configuration of each service component identified
If the service component requires VF-C
SO calls VF-C for its creation and configuration (Go to Step 6)
else if the service component requires APP-C
SO invokes location optimization to identify best data center placement for the VNF (need further clarification of this functionality)
SO calls external license manager to get a valid license to create a new instance of the VNF (need further clarification of this functionality)
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)
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 APP-C to configure the newly created VNF – (Go to Step 5)
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)
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 2b v. or 6e)
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 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.) (Go to Step 2d)
If vendor EMS (including ETSI compliant vEMS) interface is required, right EMS adaptor is used to push the configuration
If vendor VNF manager is required, right vnfm (including ETSI compliant vnfm) adaptor is used to push the configuration–(Go to Step 2g)
VF-C performs the following steps
Parser service component Descriptor and decompose it into one or several VNFs
invokes location optimization to identify best data center placement for the VNFs (need further clarification of this functionality)
calls external license manager to get a valid license to create a new instance of the VNF (need further clarification of this functionality)
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)
VF-C uses ETSI MANO compliant adaptor (directly, EMS, or s-vnfm) to push VNF configuration– (Go to Step 2d)

8. Backup