Open Network Automation Platform (ONAP) is missioned to deploy and manage VNFs on multiple infrastructure environments, including virtualized infrastructure and cloud native. Workload deployment and orchestration in multiple clouds is expected to play an essential role in ONAP operational success. This talk introduces overall ONAP architecture and orchestration workflow, and related supporting functions such as homing and optimization. Speaker: Bin Hu, Bin is an innovation thought-leader in NFV, SDN and Cloud. He is the Convener of OPNFV's Technical Community, PTL of IPv6 and PTL of Gluon in OpenStack for the next generation of NFV networking services. He was the Winner of OPNFV 2015 Annual Award.

1. Orchestrating NFV Workloads in Multiple Clouds
Bin Hu, bh526r@att.com
AT&T
Copyright 2018 AT&T Intellectual Property. All rights reserved.

2. Agenda
 ONAP Beijing Architecture
 Alignment with Long Term Target Architecture
 Deploying Workloads into Multiple Clouds

3. ONAP Beijing Architecture
Integration
VNFRequirements
Modeling(Utilities)
VNFValidationProgram
Version 2.0.3
3/15/2018
Referenced from: https://wiki.onap.org/display/DW/Beijing+Architecture

4. Alignment with Long-Term Target Architecture
• Key Architecture Principles: Modular, Microservices, Model-driven
- Modular
• Improve APIs for better consistency between components. Document them using Swagger.
• Align interfaces with industry standards, where available/appropriate
- Microservices-based
• Use OOM for onboarding, instantiation (support MSB natively), scalability
• Register with Microservice Bus (MSB)
• Use microservices best practices (e.g., separate data from the component, use common KV
stores/databases, for KV stores – prefer Consul, etc.)
- Model-driven
• Align with info/data models from the Modeling Subcommittee and external SDOs (as
appropriate)
• Explore ways to use model-driven principles inside each component as well as across various
components (SDC, SO, VFC, APPC, ..)
• Enable Integration with Other Systems via MSB/Proxy
- Enable secure communication between internal and external components

5. Deploying Workloads into Multiple Clouds
Service
Orchestrator
RUN-TIME
DESIGN-TIME
(SDC)
VNF catalog
MSB/DMAAP
Policy
Framework
A&AI/ESR OOF
1
2
3 3 444 55 6
MultiVIM / Cloud Broker (mS)
OpenStack
Plugin
Azure Plugin k8s Plugin
Other
Plugins……
6
Plugins
6
Operator Edge DCs Operator Core DCs
IPMPLS, IP etc.IP VNF VNF VNFVNFVNF
Edge Devices Hyper-Scale Cloud DCs
Service Components + Placement Requirement

6. Deploying Workloads into Multiple Clouds
1. Service Instantiation Request
2. SO
- Decomposes NSD to child NSDs
- Decomposes each NSD to individual VNFs and related networks connecting those VNFs
- Decomposes VNFs to basic deployment units (e.g. VF Module or VDU)
3. For each VNF, SO requests OOF to get best site and flavor to place deployment unit.
4. OOF, with the help of A&AI and Policy, identifies best site and flavors
- E.g. get the list of cloud infrastructure instances, get Policy such as deploy VNF on Cloud-1
5. OOF Responds to SO. SO replaces HPA information from the flavor data.
6. SO works with Cloudify/ARIA and sends deployment request to MultiVIM, which uses
corresponding Plugins (mS) to deploy workloads in multiple clouds
• Note:
- A service is represented as a (nested) NSD
- A NSD can contain multiple VNFs and inter-VNF networks
- Each VNF can contain multiple basic deployment units (e.g. VF Module or VDU)
- Each basic deployment unit (template) includes VMs/containers, internal networks, and volumes etc.
- For simplicity: one VNF is always placed in the same cloud

7. Homing
• Homing is a policy-driven, placement optimization service that
allows ONAP to deploy services automatically across multiple sites
and multiple clouds.
- Constraints include e.g. capacity, location (distance), latency, platform
capabilities, and other service specific constraints
• Service components + placement requirements -> optimal
resources
- Service requirements: e.g. latency, bandwidth, distance, proximity, affinity
regulatory, security, diversity (disaster recovery)
- Optimization objectives: e.g. latency, distance, cost, load-balancing
- Cloud capacities (e.g. SW and HW) are queried and considered
• Referenced from
http://onap.readthedocs.io/en/beijing/submodules/optf/has.git/docs/i
ndex.html

8. Thank you