The document provides an overview of demystifying OpenStack for NFV. It discusses ETSI NFV architecture, OpenStack components relevant to NFV such as Tacker, Neutron, Heat, Ceilometer, and how they work together to provide NFV capabilities. It also summarizes key NFV concepts like VNF lifecycle management, service function chaining using networking-sfc, and how monitoring is implemented using Ceilometer.

1. Demystifying OpenStack for NFV
September 2018
Trinath Somanchi
Short Term Training Program on Cloud Orchestration using SDN and OpenStack (COSOS2018)
Department of Computer Science and Engineering,
SRM IST – Chennai
TN, INDIA

2. Overview
Introduction to SDN and NFV collaborated Cloud
ETSI NFV E2E Architecture
Understanding the NFV MANO
VNF – Life Cycle Management
OpenStack – Overview
Logical Architecture
Agenda
Tacker - Features
Collaboration with Heat, Networking-sfc, Mistral and more
Open Platform for NFV
OPNFV - Introduction
NFV – What’s next ?
Evolution of Edge NFV.

3. Network Function Virtualization

4. Benefits of Network Function Virtualization
Reduced operator CAPEX and OPEX through reduced equipment costs and reduced power consumption
Reduced time-to-market to deploy new network services
Improved return on investment from new services
Greater flexibility to scale up, scale down or evolve services
Openness to the virtual appliance market and pure software entrants
Opportunities to trial and deploy new innovative services at lower risk
Network Function Virtualization – Benefits

5. Complementing the Cloud – SDN and NFV

6. ETSI NFV E2E Architecture – VNFM and NFVO
Basics
Operation Support Systems
Business Support Systems
Compute Storage Network
Virtualization Layer
Compute
Virtualizatio
n
Storage
Virtualizatio
n
Network
Virtualizatio
n
Vi-Ha
EMS - 1 EMS - 2 EMS - n
VNF - 1 VNF - 2 VNF - n
Orchestrator
Orchestrato
r
Orchestrato
r
VNF
Manager(s)
Virtualized
Infrastructure
Manager(s)
Vn-Nf
Service, VNF,
Infrastructure
Description
Os-Ma
Se-Ma
Ve-Vnfm
Or-Vnfm
Or-Vi
Vi-Vnfm
Nf-Vi
NFVI
NFV Orchestrator (NFVO)
• Network Service Orchestration using a collection of VNFs and Forwarding Graphs.
• Templatize an end-to-end Network Service using decomposed VNFs.
• Resource Checks and Resource Allocation.
• VNFs connected using Forwarding Graphs
• Described in a VNF Forwarding Graph Descriptor
• Render VNF Forwarding Graphs using SDN Controller or a SFC API.
• Ability to orchestrate VNFs across Multiple VIMs.
• PNF connectivity and configuration in end to end network service orchestration
VNF Manager (VNFM)
• VNF Catalog – repository of VNF descriptors (VNFDs) in a database
• VNF Instantiation and Termination.
• VNF Monitoring - Health and Performance Indicators.
• Self Healing and Auto Scaling.
• VNF Configuration injection during instantiation.
• VNF Image management.
• Support both simple and complex VNFs.
• Enforce placement policy - ensure efficient placement of VNFs (NUMA, CPU Pinning)

7. ETSI NFV E2E Architecture Building Blocks
VNF
• Basic block in NFV Architecture.
• Virtualized Network Element.
EMS
• Responsible for the functional management
of VNF i.e. FCAPS ( Fault, Configuration,
Accounting, Performance and Security
Management).
• This may manage the VNFs through
proprietary interfaces.
• There may be one EMS per VNF or an
EMS can manage multiple VNFs. EMS
itself can be a VNF
VNFM
• Life cycle management of VNF instances.
• Life cycle management means setting up/
maintaining and tearing down VNFs
NFVI
• NFVI is the environment in which VNFs run.
• Compute, Memory and Networking
Resources
• Virtual Compute, Virtual Memory and
Virtual Networking Resources
• Virtualization Layer – Hypervisor.
VIM
• Management system for NFVI.
• Responsible for controlling and managing
the NFVI compute, network and storage
resources within one operator’s
infrastructure domain
NFVO
• Generates, maintains and tears down
network services of VNF
• Responsible for global resource
management of NFVI resources.
OSS/BSS
• OSS deals with network management, fault
management, configuration management
and service management.
• BSS deals with customer management,
product management and order
management

8. NFV Deployment Models

9. VNF Life Cycle Management

10. OpenStack – IaaS
Source: https://www.openstack.org/assets/software/projectmap/openstack-map-v20180516a.pdf

11. OpenStack – Logical Architecture

12. The OpenStack SDN and NFV Cloud
Operation Support Systems
Business Support Systems
Compute Storage Network
Virtualization Layer
Compute
Virtualization
Storage
Virtualization
Network
Virtualization
Vi-Ha
EMS - 1 EMS - 2 EMS - n
VNF - 1 VNF - 2 VNF - n
Orchestrator
Orchestrator
Orchestrator
VNF
Manager(s)
Virtualized
Infrastructure
Manager(s)
Vn-Nf
Service, VNF, Infrastructure
Description
Os-Ma
Se-Ma
Ve-Vnfm
Or-Vnfm
Or-Vi
Vi-Vnfm
Nf-Vi
NFVI
Virtual NetworkingNeutron
WorkflowMistral
Service Function Chaining
Networking
SFC
Open Virtual Networking
Networking
OVN
Orchestration
Heat
Heat-translator
TOSCA Parser
Multi Site OpenStack Networking Tricircle
Multi Site OpenStack VIM KingBird
VNF Image Store Glance
Block and Object Store
Swift
Cinder
NFVO and VNFM Tacker
Monitor and TelemetryCeilometer
ODL SDN Controller Plugin
Networking
ODL
Monitoring and Logging Monasca
Secrets Store Barbican
VNF High Availability Masakari Disaster RecoveryFreezer

13. OpenStack – Tacker – VNFM and NFVO : Features
Feature Collaboration with Projects
TOSCA template based Orchestration of VNFs HEAT, TOSCA-PARSER
Monitoring Framework, Alarm Monitoring Mistral, Ceilometer
VNF Forwarding Graph Networking – SFC
Secured VIM credentials Barbican
Virtual Infrastructure Management Nova, Neutron, Glance and Keystone
Configuration, Logging Oslo libs

14. Tacker with OpenStack Core Components
Keystone, Glance, Nova and Neutron (Core Services)
– Provide the Virtual Infrastructure Management required for
VNF management in Direct and Indirect mode by VNFM or NFVO.
Neutron, networking-sfc supports VNF Forwarding Graph.
Nova
Neutron
Glance
Cinder Keystone
Tacker
Tacker – uses OpenStack CORE
services to manage the VNFs. OpenStack
with its CORE services forms the VIM.

15. TOSCA-Parser, HEAT-Translator and Tacker
TOSCA Parser
• Parser for TOSCA simple profile in
YAML and NFV YAML based
specification
• Sub-project of OpenStack - HEAT
HEAT Translator
• OpenStack project to map and
translate non-HEAT templates to
Heat Orchestration Templates
(HOT).
• Sub-Project of OpenStack - HEAT
Tacker
• NFVO and VNFM – NFV block in
OpenStack
• All Tacker VNFDs, VNFFGs and NS
description files are TOSCA YAML
files.
ETSI NFV TOSCA
YAML OpenStack
Tacker
(VNFM and
NFVO)
NSD
VNFD
VNFFGD
Data models
OpenStack Heat
TOSCA Parser
Heat
Translator
Compute Networking Storage Compute Networking Storage Compute Networking Storage
VIMVIM VIM
Multi Site VIM Support
Heat - OpenStack orchestration engine that automates launching
multiple composite cloud applications.
Heat-Translator - map and translate non-Heat (e.g. TOSCA)
templates to Heat Orchestration Template (HOT).
Tosca-Parser - for TOSCA Simple Profile in YAML
Heat

16. Mistral and Tacker
Network Service Descriptor (NSD)
• Mistral driver between NFVO and VNFM will
translate TOSCA template into workflow
which in turn instantiate a Network Service.
• Mistral Driver will call Mistral interfaces for
Network Service requests.
• Wait in PENDING_CREATE state for NS
until all VNFs goes to ACTIVE state.
• Decide to move forward/backward in case
of partial failure.
Scalable VNF Monitoring
• Mistral is an integral part of tacker system, a
long-live Mistral workflow action can be
used to do this kind of task.
• Tacker server will generate a VNF
monitoring workflow and execute it if there
is a VNF configured with monitor policies.
• When the workflow is removed, the VNFM
plugin will kill the mistral action via MSG
queue
Scalable VIM Monitoring
Long-live mistral workflow.
Tacker server will generate a VIM reachability
test workflow and execute it if a new vim is
registered.
The workflow and execution will be removed
once the vim is de-registered from tacker
server.
Tacker Server Mistral Workflow Conductor Server
DB
Mistral is a workflow service. Most business processes consist of
multiple distinct interconnected steps that need to be executed in
a particular order in a distributed environment.
One can describe such process as a set of tasks and task
relations and upload such description to Mistral so that it takes
care of state management, correct execution order, parallelism,
synchronization and high availability.
Mistral also provides flexible task scheduling so that we can run a
process according to a specified schedule (i.e. every Sunday at
4.00pm) instead of running it immediately.
We call such set of tasks and relations between them a workflow.
Mistral
1 2
3

17. TOSCA Template to Mistral Workflow
tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0
description: Import VNFDs(already on-boarded) with input
parameters
imports:
- sample-tosca-vnfd1
- sample-tosca-vnfd2
topology_template:
inputs:
vl1_name:
type: string
description: name of VL1 virtuallink
default: net_mgmt
vl2_name:
type: string
description: name of VL2 virtuallink
default: net0
node_templates:
VNF1:
type: tosca.nodes.nfv.VNF1
requirements:
- virtualLink1: VL1
- virtualLink2: VL2
VNF2:
type: tosca.nodes.nfv.VNF2
VL1:
type: tosca.nodes.nfv.VL
properties:
network_name: {get_input: vl1_name}
vendor: tacker
VL2:
type: tosca.nodes.nfv.VL
properties:
network_name: {get_input: vl2_name}
vendor: tacker
---
version: '2.0'
# input params
task-defaults:
on-error:
- delete_vnf
tasks:
create_vnf:
description: Request to create a VNF.
action: tacker.create_vnf body=<% $.body %>
input:
body: <% $.body %>
publish:
vnf_id: <% task(create_vnf).result.vnf.id %>
vim_id: <% task(create_vnf).result.vnf.vim_id %>
mgmt_url: <% task(create_vnf).result.vnf.mgmt_url %>
status: <% task(create_vnf).result.vnf.status %>
on-success:
- wait_vnf_active
wait_vnf_active:
description: Waits till VNF is ACTIVE.
action: tacker.show_vnf vnf=<% $.vnf_id %>
retry:
count: 10
delay: 10
break-on: <% $.status = 'ACTIVE' %>
break-on: <% $.status = 'ERROR' %>
continue-on: <% $.status = 'PENDING_CREATE' %>
publish:
mgmt_url: <% task(wait_vnf_active).result.vnf.mgmt_url %>
status: <% task(wait_vnf_active).result.vnf.status %>
on-success:
- delete_vnf: <% $.status = 'ERROR' %>
delete_vnf:
description: Request to delete a VNF.
action: tacker.delete_vnf vnf=<% $.vnf_id %>

18. Ceilometer and Tacker
Tacker
(TOSCA)
Alarm Framework Ceilometer
The Ceilometer project is a data collection service that
provides the ability to normalise and transform data across
all current OpenStack core components with work
underway to support future OpenStack components.
Ceilometer is a component of the Telemetry project. Its data
can be used to provide customer billing, resource tracking,
and alarming capabilities across all OpenStack core
components.
Ceilometer
1 2
Monasca
Custom
Driver
VNF
• ETSI MANO architecture describes to monitor the VNF to take appropriate action such as fault
management, performance management. Monitoring became an important aspect in MANO
architecture.
• Monitoring Policy in TOSCA template – for single and Multiple VDUs.
• Default backend actions : scaling, respawn, log, and log_and_kill.

19. Ceilometer and Tacker
tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0
description: Demo example
metadata:
template_name: sample-tosca-vnfd
topology_template:
node_templates:
vdu1:
type: tosca.nodes.nfv.VDU.Tacker
capabilities:
nfv_compute:
properties:
disk_size: 1 GB
mem_size: 512 MB
num_cpus: 2
properties:
image: cirros-0.3.4-x86_64-uec
mgmt_driver: noop
availability_zone: nova
vdu1_cpu_usage_monitoring_policy:
type: tosca.policies.tacker.Monitoring
targets: [vdu1]
triggers:
resize_compute:
event_type:
type: tosca.events.resource.utilization
implementation: Ceilometer
metrics: cpu_util
condition: utilization greater_than 70%
threshold: 70
period: 60
evaluations: 1
method: average
comparison: gt
action:
resize: vdu1_scaling_policy
CPU usage monitoring Policy

20. Networking-SFC with Tacker - VNFFG
• Abstract VNFFG TOSCA definitions are rendered into
Service Function Chains (SFCs) and Classifiers.
• The SFC makes up an ordered list of VNFs for traffic to
traverse, while the classifier decides which traffic should go
through them.
• Similar to how VNFs are described by VNFDs, VNFFGs are
described by VNF Forwarding Graph Descriptors (VNFFGD).
• After creating a VNFFGD, a VNFFG is instantiated by a
separate Tacker command. This action will build the chain
and classifier necessary to realize the VNFFG.
Service Function Chaining Extension for OpenStack
Networking
Fundamentally SFC is the ability to cause network packet
flows to route through a network via a path other than the
one that would be chosen by routing table lookups on the
packet’s destination IP address.
It is most commonly used in conjunction with Network
Function Virtualization when recreating in a virtual
environment a series of network functions that would have
traditionally been implemented as a collection of physical
network devices connected in series by cables.
Networking-sfc
NFVO / VNFM / VNFFG API
Tacker
Heat
Neutron
(networking-sfc)
SDN Controller
OVSDB
OVSDB
VNF
vRouter VNF 1 VNF 2
Compute Node A
OVSDB
VNF
DPI VNF 1 VNF 2
Compute Node A
VNFD
VNFD
VNFD
VNFFGD
VNFD
NSD
1
2
3
4

21. Barbican with Tacker
Designed for the secure storage, provisioning and management
of secrets. It is aimed at being useful for all environments,
including large ephemeral Clouds.
* Secrets API. It provides access to the secret / keying material
stored
in the system, including Private Key/Certificate/Password/SSH Keys
* Secret Metadata API. It allows a user to be able to associate
various
key/value pairs with a Secret.
* Containers API. It creates a logical object that can be used to
hold secret references.
* ACL API. It supports access control for secrets and containers.
* Certificate Authorities API. It is used as an interface to interact
with Certificate Authorities.
* Quotas API. It limit on the number of resources that are allowed
to be created.
* Consumers API. It is a way to register as an interested party
for a container.
Why to collaborate with a OpenStack project that deals with
Security?
Tacker supports registering VIM with credentials, which are used by NFVO
and VNFM to operate resources in NFVI. The credentials include username,
password, and project information.
When Tacker Server is behind a load balancer, then the operation will fail if
the request is not
fulfilled by the server node which created and stored the fernet key. We need
a possible solution for syncing the keys across multiple server nodes. This
adds operational complexity for tacker administrators as they add tacker-
server instances for scaling.
Tacker uses Barbican’s Secrets API to restore the password of
VIM. And in future, we can use Barbican to support TLS in
Tacker API
Barbican

22. Oslo Libraries
Oslo – brings deployment and development experiences consistent across OpenStack projects.
•OpenStack projects share many common design patterns and implementation details.
•Early in the history of OpenStack this resulted in a lot of code being copied out of one project into another.
•The Oslo project was created to address this situation, and to provide a home for common code used by multiple other OpenStack projects.
•Adopting oslo libraries makes a project more similar to the rest of OpenStack, and that consistency in turn improves the Operator/Deployer experience.
Well known Oslo Libraries (not limited to) –
oslo.config : Provides tools for managing configuration option definitions, validation, configuration file
parsing, and command line option processing.
oslo.messaging: Implements common inter-process communication patterns such as notifications and
RPC. It includes drivers for different backends such as RabbitMQ, AMQP 1.0, and ZMQ. This pluggable
backend pattern is common across OpenStack as a way to provide options for deployers familiar with
different tool stacks.
oslo.log: Wrapper around Python’s standard logging tools, coupling them with oslo.config and applying
OpenStack-specific requirements.

23. Tacker Architecture
Heat
OpenStack
Nova &
Neutron
Infra
Driver
Tacker
NFVO / VNFM / SFC API DB
Monitoring
Driver
Management
Driver
SFC Driver
SDN Controller
OVS
Mgmt NetTenant Net
Trend
Micro
VNF
VNFVPN
VNF
6Wind
Turbo
Router
MngrMngr
Monitoring
feedback
Service
Configuration
VNF Forwarding
Graph
YAML
YAML
YAML
YAML
YAML
Monitoring Configuration
VNF
LCM
NFVI - Compute Node
VNF On-Boarding,
Orchestration
&
Life Cycle Management
Network Service Orchestration
&
VNF Forwarding Graph
Trend Micro VNF
6WindVNF
Brocade VNF
VNF/NS/VNFFG
TOSCA Templates
Horizon GUI
(or) CLI
1
2
3 4
5
6
7

24. Demo

25. OPNFV - Introduction
Source: https://docs.opnfv.org/en/stable-fraser/release/overview.html
OPNFV
- Provides blueprints on how to deploy and
configure different open source communities
together.
- Requirements, use-cases and validation.
- OpenStack as VIM.

26. OPNFV – Projects
OPNFV Project OpenStack Project(s)
NetReady – Investigate and evolve OpenStack Networking to
support NFV usecases.
Neutron – Gluon
Connect network service providers with VMs
Doctor – Create a fault management framework for HA. Ceilometer, Aodh – Notification/Alarm
Vitrage, Congress – Monitoring and Analysis
Multisite – Connected NFV deployments across multiple
geographical locations
OpenStack Core Services,
Kingbird, Tricircle – Centralized Service for multi-region
OpenStack deployments and Networking automation across
neutron servers.
SFC – Provides ordered list of network services stitched
together to create a Network Service Chain.
OpenStack Core Services,
Tacker - VNFM and NFVO, Neutron – Networking-SFC
OVN – Open Virtual Networking for Containerized VNFs and
Edge NFV devices.
Neutron – Networking-OVN

27. Evolution of Edge NFV

28. @OpenStac
k
That’s all folks.
Questions?
openstack openstack OpenStackFoundation