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 3rd 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: 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.).
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
Data Collection & Analytics
DMaaP / API Gateway
Policy Creation
Analytic Application
Creation
Recipie/
Engineering Rules &
Policy Distribution
Catalog
Multi-VIM
Infrastructure
Interface
Config
Database
Infra. Adaption Layer
Open
Stack
AWS
Azure
App-C
SDN-C
Service Logic Interpreter
Config
Database
Adaption Layer
Adaption Layer
…
Infrastructure
Controllers
Netconf
Adaptor
VNF 1
Yang
Adaptor
3rd Party
Adaptor Cont
VNF 2
CLI
Adaptor
VNF 3
Netconf
Adaptor
ETSI Comp
Chef
Adaptor Adaptor
VNF 4
VNF 5
4
Service Logic Interpreter
EMS
VNF 6
Vnfm
EMS
Adaptor(s) Adaptor(s)
s-vnfm
VNF 7
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 2e)
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 3rd party controller for WAN configuration – (Go to Step 2f)
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 vEMS) 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 2g)
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
Data Collection & Analytics
DMaaP / API Gateway
Policy Creation
Analytic Application
Creation
Recipie/
Engineering Rules &
Policy Distribution
Catalog
Multi-VIM
Infrastructure
Interface
Config
Database
Infra. Adaption Layer
Open
Stack
AWS
Azure
Adaption Layer
…
Infrastructure
Controllers
Netconf
Adaptor
VNF 1
Config
Database
Service Logic
Interpreter
Adaption Layer
Service Logic Interpreter
3rd Party
Yang
Cont.
Adaptor
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 Adaptor(s) Adaptor(s)
EMS
VNF 6
s-vnfm
VNF 7
VNF 7
Sample Service Instantiation Flow with Option 2
1)
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),
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 2b v. or 6e)
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 3rd party controller for WAN configuration – (Go to Step 2e)
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 2d)
c. If vendor EMS (including ETSI compliant vEMS) 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 2g)
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 2d)
3)
4)
5)
6)
7
Backup