Orchestration and Controller Architecture Alignment
Vimal Begwani
AT&T
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 (VeVnfm-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.).
o Reduces Overlaps, Enhancements / Changes Shared Across All Controllers, Simplifies Deployment
 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

Key considerations and principles.




2
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
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
3
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 interface is required, right EMS adaptor is used to push the configuration
d. If vendor VNF manager is required, right vnfm adaptor is used to push the configuration– (Go to Step 2g)
4
Release 1 Architecture: Option 2
1. Same as option 1 but all the ETSI
compliant adaptors have been put on
a separate module.
2. App-C will have a dispatcher to send
configuration requests to ETSI
compliant VNFS to VF-C
External API Gateway
ONAP Portal
SDC
Service Orchestrator
(Integrated MSO & NFV-O)
Active & Available Inventory
DMaaP / API Gateway
Data Collection & Analytics
Service Workflow
Design
Resource Workflow
Design
Policy Creation
Analytic Application
Creation
Recipie/
Engineering Rules &
Policy Distribution
Catalog
Multi-VIM
Infrastructure
Interface
SDN-C
Config
Database
Infra. Adaption Layer
Open
Stack
AWS
Azure
VF-C
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
CLI
Adaptor
Netconf
Adaptor
VNF 3
Chef
Adaptor
other
Adaptor
VNF 4
VNF 5
5
VF-C
App-CDispatcher
ETSI Compliant
Adaption Layer
ETSI
Vnfm
EMS
Adaptor Adaptor(s) Adaptor(s)
EMS
VNF 6
s-vnfm
VNF 7
VNF 7
Sample VNF Instantiation Flow with Option 2:
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 the VNF requires ETSI MANO compliant interface, APP-C dispatcher sends request to VF-C with parameters
d. VF-C uses ETSI MANO compliant adaptor (directly, EMS, or s-vnfm) to push the configuration– (Go to Step 2g)
6
Release 1 Architecture: Option 3
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
Service Logic Interpreter
Config
Database
…
Infrastructure
Controllers
Netconf
Adaptor
VNF 1
Yang
Adaptor
3rd
Party
Adaptor Cont
Service Logic Interpreter
Adaption Layer
Adaption Layer
CLI
Adaptor
s-vnfm
VNF 7
7
App-C
SDN-C
VNF 8
Netconf
Adaptor
VNF 2
Chef
Adaptor
VNF 3
ETSI Comp
Adaptor
VNF 4
VNF 5
EMS
Adaptor(s)
EMS
VNF 6
Sample VNF Instantiation Flow with Option 3:
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. If the vnf uses vendor VNF-M then pass all the details to vendor VNF Manager, (Go to Step 2g)
b. SO invokes location optimization to identify best data center placement for the VNF
c. SO calls external license manager to get a valid license to create a new instance of the VNF
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 2d)
4) SDN-C controller performs the following functions (could be multiple calls from SO)
a. 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
b. SDN-C performs overlay network configuration
c. SDN-C performs required WAN network configuration
d. SDN-C could call legacy or 3rd party controller for WAN configuration – (Go to Step 2e)
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 interface is required, right EMS adaptor is used to push the configuration
8
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.).
9