Mitel

NFV Quick
Start Guide
GANESH RAAJA N
 Proprietary Hardware

What is NFV? Hardware EOL NFV

The goal of NFV is to decouple network functions from dedicated

hardware devices and allow network services that are now being
carried out by routers, firewalls, load balancers and other dedicated
hardware devices to be hosted on virtual machines (VMs). Once the
network functions are under the control of a hypervisor, the
services that once require dedicated hardware can be performed on
ETSI High level NFV
Framework
Mitel NFV
• Already the mOne products are virtualized and can be
deployed on a general purpose hardware as a virtual machine
• In NFV solution the elasticity of the network is automated to
support scale-in, scale-out.
– Scaling out – add resource instances (Virtual Machines)
– Scaling in – remove resource instances (Virtual Machines)
• Based on the real time traffic, the network can scale-in or
scale-out
• Each node in NFV is termed as “VNF” (Virtual Network
Function). Ex. TAS VNF, ePDG VNF etc.
Mitel NFV Architecture
NFV
reference
Architectu
re
framework
 NFV
Protocols,
Interfaces
Protocols/Interfaces

• Interfaces
– NETCONF (For managing each node – configuration, monitoring etc.)
– REST (HTTP based interface for provisioning/notifications)
– CLI prompt

• Data schema – YANG data model

• Note: mOne platform SW is traditionally based on MySql based
configuration framework. To support various north bound interfaces like
NETCONF, CLI, REST, it will be migrated to Yang based data model. (RFC
6020)
Why NETCONF?
Disadvantages of existing management methods
• CLI
– Lack of transaction management
– No structured error management
– Ever changing structure and syntax of commands
– Designed to be used by humans and not an API for programmatic access.
• SNMP
– Mainly used for performance and monitoring applications
– Use of the UDP protocol
– Lack of useful standard security & commit mechanisms
What is NETCONF?

• NETCONF is a protocol defined by the IETF to “install, manipulate, and

delete the configuration of network devices”. NETCONF operations are
realized on top of a Remote Procedure Call (RPC) layer using an XML
encoding and provides a basic set of operations to edit and query
configuration on a network device.
NETCONF Capabilities
• The NETCONF protocol was designed to address the
shortcomings of existing practices and protocols for
configuration management.
• Distinction between configuration and state data
• Multiple configuration data stores (candidate, running, startup)
• Configuration change transactions
• Configuration testing and validation support
• Selective data retrieval with filtering
• Streaming and playback of event notifications
• Extensible procedure call mechanism
 module epdg

Sample
{
list ext_ip
{
namespace "http://mitel.com/ns/epdg/1.1";
Yang data
key "ip_addr";
max-elements 128;
leaf ip_addr { prefix mitel;
type string;

model }
leaf maskSize {
type uint32;
include
include
mitel-platform;
mitel-appcommon;
default 0; include mitel-cdr;
}
leaf fk_ext_ip_intf { include mitel-diam;
type leafref { include mitel-dns;
path "/sys/platform/ext_ip_intf/intf";
} include mitel-ikemgr;
} include mitel-ldap;
leaf ip_config_type {
type enumeration {
include mitel-utimacoli;
enum EXT_IP_UNKNOWN; include mitel-fpath;
enum EXT_IP_VIRTUAL; include mitel-epdg;
enum EXT_IP_PHYSICAL;
}
mandatory true; container sys {
}
leaf logicalCardId {
uses platform;
type uint32; uses appcommon;
default 0;
}
uses cdr;
leaf fkcomponent { uses diam;
type leafref { uses dns;
path
"/sys/platform/component/name"; uses ikemgr;
} uses ldap;
}
leaf fkprot_grp {
uses utimacoli;
type leafref { uses fpath;
path "/sys/platform/prot_grp/name";
}
uses epdg;
} }
} }
 VIM
(Virtualized
Infrastructure
Manager )
Overview of Cloud
Computing
• Cloud Computing :
Cloud computing is a type of computing that relies on sharing computing
resources rather than having local servers or personal devices to handle
applications
VIM

• The virtualized infrastructure manager (VIM) is a key

component of the NFV-MANO architectural framework.
It is responsible for controlling and managing
the NFV infrastructure (NFVI) compute, storage,
and network resources, usually within one
operator’s infrastructure domain.
• In Mitel NFV solution OpenStack based VIM layer
manage spawning of various VNFs required for the
network viz. TAS/ePDG etc. based on the instructions
What is Openstack?
• Openstack is a community of open source developers,
participating organizations and users who are building
and running the open source cloud operating system.
OPENSTACK COMPONENTS
Openstack Releases
Release
name
Release
date
Included Component code names

21 October
Austin Nova, Swift
2010
3 February
Bexar Nova, Glance, Swift
2011
15 April
Cactus Nova, Glance, Swift
2011
22
Diablo September Nova, Glance, Swift
2011
Essex 5 April 2012 Nova, Glance, Swift, Horizon, Keystone
27
Folsom September Nova, Glance, Swift, Horizon, Keystone, Quantum, Cinder
2012
Grizzly 4 April 2013 Nova, Glance, Swift, Horizon, Keystone, Quantum, Cinder
17 October
Havana Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, Heat, Ceilometer
2013
17 April
Icehouse Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, Heat, Ceilometer, Trove
2014
16 October
Juno Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, Heat, Ceilometer, Trove, Sahara
2014
30 April
Kilo Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, Heat, Ceilometer, Trove, Sahara, Ironic
2015
16 October Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, Heat, Ceilometer, Trove, Sahara, Ironic,
Liberty
2015 Zaqar, Manila, Designate, Barbican, Searchlight
Scheduled Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, Heat, Ceilometer, Trove, Sahara, Ironic,
Mitaka
7 April 2016 Zaqar, Manila, Designate, Barbican, Searchlight
Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, Heat, Ceilometer, Trove, Sahara, Ironic,
6 October
Newton Zaqar, Manila, Designate, Barbican, Searchlight, Magnum, aodh, cloudkitty, congress, freezer,
2016[120]
mistral, monasca-api, monasca-log-api, murano, panko, senlin, solum, tacker, vitrage, watcher
Sealed-disk images – qcow2
The images stored in Glance are sometimes called
sealed-disk images. These images are disk images that
have had the operating system installed but have had
things such as Secure Shell (SSH) host key, and
network device MAC addresses removed. This makes
the disk images generic, so they can be reused and
launched repeatedly without the running copies
conflicting with each other.
qcow2 is a file format for disk image files used by
QEMU, a hosted virtual machine monitor.[1] It stands for
"QEMU Copy On Write" and uses a disk storage
VNFM
Descriptors
• VNFM – is the brain for scale-in scale-out in the NFV solution
• NSD – Network Service Descriptor
• VNFD – VNF Descriptor
• VDU – For each VNF, there can be multiple virtual deployment
units (VDUs). Each VDU may contain multiple VNF components
which are characterized by their unique connection points.
Each VDU corresponds to one virtual machine.
• VNFC – ID assigned to a VDU
Functionalities
• VNFM is a Java based product
• REST interface towards the VNF for LCM operations
• REST interface subscriptions/notification for LCM parameters
towards the VNF
• NETCONF server interface towards CMS
• For the NETCONF interface, ConfD is used
• EPB (End Point Broker Library) library front ends the VNFM
towards the VNF. The EPB library could be customized for each
VNF type to define the state transitions and REST messages.
NSD Example

• Sample NSD

TAS_NSD_V9.0.json
VNFD Example

• Sample VNFD

TAS_VNFD_V9.0.json
CMS
Functionalities
• CMS is a Java based product which will manage 1000s
of VNFs
• CMS will be pre-provisioned with different type of VNF’s
schema
• CMS will be pre-provisioned with the DB configuration
for various VNF’s that will be managed by the CMS.
• CMS is a NETCONF client towards VNF and VNFM
• CMS will present the GUI as an auto-generated web-
page, from the YANG data model.
 VNF
Instantiation
NFV Solution - Components
1. Standard GUI for managing all the
VNFs
2. DB configuration push to VNF 1. Manage VIM
3. Pull KPIs, Events, Alarms from the 2. Scale-in/scale-
VNF and archive out VNFs
based on LCM
CMS threshold
VNFM
(VNF Manager)
Glance
(Images
Nova, )
Cinder,
Compute Celiomete Neutron Keystone
Nodes r, (Networkin (authenticati
Heat g) on)

VIM layer
(Openstack)
NFV Solution – Offl ine setup

CMS
Upload NSD, NSD’s,
tas tas tas
1 2 3
epdg
1
epdg
2
epdg
3
VNFD (VDU) VNFD’s

TAS Schema VNFM

ePDG
and Schema and Upload qcow2
DB dump for DB dump for image for TAS &
3 different 3 different EPDG
TAS VNFs ePDG VNFs

Qcow2 is stored
Offline setup completed!!! on the Glance
VIM
Compute Nodes Glanc KS
e
 NFV Solution – VNF NETCONF interface
REST interface

start
Instantiate VNF
CMS
Add VNF(VNF id) NSD’s,
tas tas tas epdg
1 2 3
epdg
1
epdg
2 3 VNF Started VNFD’s
NETCONF Server VNFM
Configuration push / ACK
IP/port opened Configure VNF (deployment parameters) /ACK
TAS- Notify (InitSucess)
Notify (ConfigureSucess)
1
Start/ Notify(StartSucess)
pm, sm,
Allocate Virtual Resource
mcmserver,
emMgr, confd are / ACK
up.
VIM
Compute Nodes Glanc KS
e
NFV Solution – VNF Scale-in/scale out

CMS
NSD’s, EPB library
tas tas tas
1 2 3
epdg
1
epdg
2
epdg
3
VNFD’s will monitor
the values.
VNFM Based on the
threshold
VNFM Subscribes for LCM monitoring parameters levels, it will
TAS- EPB Library
VNF sends the LCM monitoring decide on
1
parameters scale-in or
At periodic interval scaleout
operations.

VIM
Compute Nodes Glanc KS
e
NFV impact
on mOne
platform
mOne platform changes
• Program startup sequence and procedure are changed (impact on SM, pm)
• ConfD – a third party commercial software is integrated with mOne platform for configuration
and OAM framework
• MySql based data base is deprecated. ConfD’s CDB is introduced
• mcmserver is modified to download DB tables from ConfD based data base
• tmmserver, evmserver, perfMonServer are modified to access ConfD APIs to report OAM data
• New process called emMgr is created to spawn ConfD process and manage its health
• A new process called notifyMgr is created to handle REST notifications towards VNFM for LCM
parameters
• A library termed EmWrapper is developed over the ConfD APIs as an abstraction layer for the
applications like mcmserver, tmmserver etc.
• BUILD script will package ConfD package and related scripts from vendor/ConfD
• On the test bed confdSetup.sh has to be executed to install ConfD. This will be integrated
with the installation script soon.
• Target platform: rhel_7_2_x86_64
 What is ConfD?
North bound client can
perform Create, Retrieve, Transport Operational • Apart from that ConfD
Update, Delete (CRUD) data (KPIs, alarms, will perform Yang
operations on the CDB events) to the north validations/constraints.
bound agent • Invoke action call backs
The north bound client
can use NETCONF, REST,
CLI, SNMP or WebUI to
perform these operations.

ConfD Yang
process
CDB schem
a

Proprietary TCP connection

libconfd.
a Transfer operational data
mOne Download configuration & (KPIs, events, alarms) to north
Application Subscribe for DB notifications bound
 NETCONF CLI REST Web UI

mOne ConfD
integration YANG data
schema model Compilation YANG data
represented as model
.fxs

Conf-D application

DB values
CDB

TCP Sockets

libconfd.so libconfd.so
Legend
EmWrapper EmWrapper
– Conf-D provided
Data
Data provider
provider
applications – New wrapper library to be developed
MO applications
(tmmServer/
(tmmServer/
perfMon etc.) – YANG data model to be defined for
existing configuration.
– Existing mOne appln.
Configuration download

• All the mOne applications will continue to follow the

existing downloadTable procedure towards the
mcmserver.
• mcmserver will download the configuration table from
ConfD and relay it to the application.
• DB notifications will be delivered to the applications
as per the existing mechanism from the mcmserver
oid_index
• Current mOne platform/application uses the oid_index column
in the DB schema as a auto-increment primary key.
• Since oid_index is not human understandable, it has to be
deprecated to the operator.
• Hence oid_index will be deprecated from the YANG data model.
• But the EmWrapper library will internally generate the
oid_index and maintain the integrity of the dependent foreign
key references to avoid impact across applications.
• To achieve this, the module owners need to update the .cfg file
to the new format
Configuration download
contd…
• .cfg files need to be updated with a new primary key, as the
oid_index is not supposed to be exposed to the operator (CMS).
• schema_transfer.py has to be executed to convert the .cfg files
to produce a new format of .cfg files. The new format files have
to be committed to the repository with the original file name.
$ python schema_transfer.py key ext_ip.cfg

• The BUILD procedure will generate the .yang files from the .cfg
files and will be available in mmx/oam/schema/yangFiles
• The BUILD script also generates the .fxs files for the yang
files. .fxs file
 Example schema change
SUBCOMPONENT ext_ip 128 32 {
{ scope PUBLIC
SUBCOMPONENT ext_ip 128 32 {
}
{ UINTEGER oid_index { size 4 NOTNULL editable 0 default 0xffffffff
{ UINTEGER oid_index {
PRIMARYKEY }}
{ IPADDR_STR ip_addr { size 64 default 0 editable 1 NOTNULL UNIQUE }}
size 4
nullable NOTNULL
editable 0
default 0xffffffff
key INDEX }
}
{ IPADDR_STR ip_addr {

Schema_transfer.py size 64
default 0
editable 1
nullable NOTNULL
key PRIMARYKEY
}
schema_transfer.py

• [graaja@devrh62-1 schema]$ python schema_transfer.py

key_info ext_ip.cfg
• [graaja@devrh62-1 schema]$ cat key_info
ext_ip ip_addr
[graaja@devrh62-1 schema]$
• Generated file name: ext_ip.cfg_new
• Commit the ext_ip.cfg_new as ext_ip.cfg under
mmx/defs/schema as ext_ip.cfg
Operational Data [ KPIs,
events, alarms]
• Operational data refers to
– KPIs
– Events
– Alarms
• Operational data are generated by the
VNF.
• They have to be stored persistently for
offline analysis.
• In NFV-VNF solutions VNFs is not
supposed to store operational data in
itself. It has to be stored in a
centralized server such as CMS/EMS.
KPI’s
CMS VNF

<hello> capability exchange

(pulled by
VNF1 provides notification stream: tmmserver, evmserver
NETCONF notification subscription stream:tmmserver, evmserver

CMS] NETCONF subscription OK

VNF (tmmserver) generates KPI data.
Stores it in the CDB(cdb-oper).
Generates an empty NOTIFICATION
to CMS
CDB

NETCONF Notification (stream: tmmserver)

NETCONF <rpc> get CDB

NETCONF rpc reply (contains KPI values)

NETCONF <rpc> action Tailf:actionpoint gets invoked. Action

call back removes the CDB entries.
CDB

NETCONF <rpc> ok
Alarms, CMS VNF

events
<hello> capability exchange
VNF1 provides notification stream: tmmserver, evmserver

(pushed to NETCONF notification subscription stream: tmmserver, evmserver

CMS] NETCONF subscription OK

VNF (evmserver) generates alarms/

events data. Stores it in the CDB(cdb-
oper). Generates a NOTIFICATION with
the alarm/event details to the CMS CDB

NETCONF Notification (stream: evmserver) with alarm/event details

NETCONF <ok>
 VNF
ConfD/
EMS VNFM NotifMgr PerfMon SM PM MCM APPs
emMgr APPs

Initial Instantiate VNF (VNFD)

VNFM gets VM resources through NFVO/VIM, then VMs boot, PM is started
If system processes

system
NULL OOS
exist and not spawned
yet
1. Spawn emMgr
2. spawn MCM

startup
4. Spawn system-level processes 3. OK

Spawn
INS
SYSINS

5. MSG_PM_REPORT_SYS_READY

Instantiated-
Not-
6. POST Configured
api/running/sys/
platform
7. VNF instance is created
{vnf}
6a. 200 OK 8. Notify VNF created
8a. Notify event URI
10. NETCONF 9. Subcribe
port is opened, Instantiated-
VnfStateChange
ready to receive Configuring
NETCONF msgs

11. InitSuccess
13. POST /vnfm/event 12. InitSuccess Event
14. Add VNF instance {event : Event
(systemId, InitSuccess}
netconf address)
15. Edit-configure
(Application specific parameters) 16. EMS Configuration download
15a. Ack 17. Notify EMS
configuration done

Instantiated-
Configured-
Inactive
18. Configue
19. Configure Success
20. POST /vnfm/event Success Event
{event : Event
ConfigureSuccess}
 VNF
ConfD/
VNFM notifyMgr perfMon SM PM MCM APPs
emMgr APPs
VNF VNF has been instantiated and configured, inactive

start 1. POST
Instantiated-
Configured-
Inactive
/api/running/sysops
lcm/_operations/start
If PM is Configuring/
2. start action
OOS, it spawns all app
Instantiated- processes
Configured-
Activating
SYSINS

5. MSG_SM_
ACTIVATE 6. PM spawns app processes
7. APP Maint

8. Register
Maintenance tables
9. Download
tables
10. INS
INS

11. MSG_PM_
REPORT_CARD
_INSERVICE
12. MSG_SM_
NOTIFY_CARD
_RUN_INFO
(SYSTEM_ 13 MSG_SM_NOTIFY_
READY) SYSTEM_READY
Instantiated-
Configured
-Active

14. start action done {successful}

15. 200 OK
{successful} 17. reports 16. reports
18. POST /vnfm/event StartSuccess StartSuccess
(event= event event
StartSuccess)
readShm output
AM-root@0-9:/root> readShm
------------- GEO State -----------------------
GEO OOS
------------- System Ovld Level --------------
0

----------- Card Status: ------------------------------------------

Shelf-Slot Node Protection Group Type State Logical
Card Id Physical IP Virtual IP Fabric IP OVLD Level
0-9 1 - AM CM_TYPE_1_1_A_A STATE_OOS Invalid
172.16.33.29 0.0.0.0 172.16.73.29 N/A
------------- VNF State -----------------------
vnfmLcmAddress : 10.3.8.78:9090
vnfmMonAddress : 10.3.8.78:9090
netconfAddress : :2022
vnfId : 6666-e89b-12d3-a456-1234500001
issuedEvent: Start Success
vnfState : Configured Active
AM-root@0-9:/root>
VNF state change

• readShm output states

• vnfState :Initializing->Not Configured (service IMS start)

• vnfState :InitSuccess (after post vnf table)
• vnfState :Configured Inactive (after config done/post endindicator)
• vnfState :Configured Active (start vnf)
• vnfState :Stop Success (stop vnf)
 Other VNF’s - sDNS

• sDNS is an independent VNF which performs the load-sharing of the

available VNF’s for the new dialog creating messages. Ex. INVITE

TAS1 tas.abc1.tmo.net

DNS query
for a new sDNS TAS2 tas.abc2.tmo.net
call

tas.tmo.net
TAS3 tas.abc3.tmo.net
 Other Nodes – Session DB
• In NFV solution, all the VNF’s will be active. There is no HA pair proposed for
the solution.
• To achieve high availability a centralized session store will be used.
• Each VNF will store it’s call session data to the Session DB through the DB
Adapter APIs.
• When a new VNF takes over the load of a another VNF, it has to pull the
session data from
TAS the
TAS1Session DB and re-construct the calls for serving the
goes down
1
ongoing calls.
TAS
2
Session
DB
TAS
3
Pull Session Data
on demand to
New VNF takes over TAS reconstruct the
1
TAS1’s role required calls
Other Nodes – CAS
Centralized Analytics System (CAS) will collect CDRs, TRLs and Logs from the
VNF’s.
This product will be evolved as an “MSIS running on mOne based platform”.
UnFlavoured VNF

• Since all the VNFs are active, on any VNF’s failure, a new VNF has to be
instantiated afresh and it should be brought in-service.
• The time taken to bring up a new VNF should be minimal.
• Un-flavoured VNF is a VNF which is up and running with the global
configuration. When an active VNF fails, the VNFM can readily select an un-
flavoured VNF and instruct the CMS to push the node specific data and
bring it to in-service.
• For example, the operator can design the network such a way that for a 100
active TAS VNF’s there could be 5 un-flavoured VNFs for quick takeover of
services.
Installing ConfD in the test
bed
• confdSetup.sh and confdPackage.tar are packaged along with the mOne
product package.
• confdSetup.sh needs to be executed in the target machine. It will unzip the
ConfD tar ball and install ConfD and setup the required environment.
• ConfD gets installed under /opt/confd/confdInstallDir
• Installation script should also copy the .yang files from the package to
/usr/IMS/current/yangFiles folder in the target machine
ConfD CLI

• To invoke cli in the test bed, type ‘cli’ from anywhere:

AM-root@0-9:/root> cli
admin connected from 10.10.192.104 using ssh on 0-9.mavenir1.com
admin@0-9> show configuration sys
Possible completions:
appcommon cdr platform sdns
admin@0-9> show configuration sys appcommon
ConfD CLI continued
• Setting a value to the DB
appcommon cdr platform sdns
admin@0-9> conf
Entering configuration mode private
[ok][2017-01-04 12:04:05]

[edit]
admin@0-9% set sys sdns sdns_
Possible completions:
sdns_appvnf sdns_appvnf_params sdns_rootdomain sdns_server
admin@0-9% set sys sdns sdns_rootdomain
Possible completions:
<domain:string>
admin@0-9% set sys sdns sdns_rootdomain xyz
[ok][2017-01-04 12:05:03]
admin@0-9% commit
ConfD CDB Back up/Restore

• Backup – pretty format:

admin@0-9% save /root/db_backup
• Backup – XML format*:
/opt/confd/confdInstallDir/bin/netconf-console get-config.xml >
dbbak.xml
get-config.xml

• DB backup restore:
AM-root@0-9:/opt/confd/confdInstallDir/bin> ./confd_load -lm
dbbak.xml
* Note: For invoking netconf SSH client, the machine should have
paramiko 3rd party Python package.
ConfD CDB Back up/Restore

In built scripts are provided for taking CDB backup and restoring.
• ./cdbbackup
Invoke 'cdbbackup' to take an XML backup of the CDB configuration for 'sys‘

• ./cdbrestore
Invoke 'cdbrestore' to restore XML DB backup to ConfD CDB, It will merge the
config.
Export MySql DB Dump to
CDB?
This tool is to convert MySQL data into NETCONF xml data which can be loaded into CDB.
Steps:
1. get db full dump

2. format change and saved to file new.sql

python change_insert_format_not_check_default.py
dump_only_data_11291608.sql
cp new.sql /root/UCG-CONFIG/uag_transfer/mysql_data/

3. covert new.sql to output. xml

python sql_to_xml.py /root/UCG-CONFIG/uag_transfer/yang/ /root/UCG-
CONFIG/uag_transfer/mysql_data/ output.xml load False

• http://maven/sites/eng_gen/GenDocs/NFV/Test/sql2xml_transfer_v7_2.zip
References
• NFV maven page:
http://maven/sites/eng_gen/GenDocs/Forms/AllItems.aspx?RootFolder=%
2fsites%2feng_gen%2fGenDocs%2fNFV&FolderCTID=0x012000BF7C7FD08
232A64EA69547999D7FFB28
• mOne platform HLD: http://
maven/sites/eng_gen/GenDocs/NFV/3%20HLDs/HLD_VNF_Platform_Design.d
ocx
• EmWrapper HLD: http://
maven/sites/eng_gen/GenDocs/NFV/3%20HLDs/ConfD-mOne%20integration
%20HLD_v_06.docx

• Schema change guide: http://

maven/sites/eng_gen/GenDocs/NFV/3%20HLDs/VFN_Platform-Schema_Confi
g_File_Guide_v0.1.docx
• ConfD Related presentation and training videos:
References
• Call flow document
http://maven/sites/eng_gen/GenDocs/NFV/2a%20SystemsEng%20(FRSs)/
NFV%20Call%20Flows_v1c.pdf
• NFV POC preparation checklist
http://
maven/sites/eng_gen/GenDocs/NFV/NFV%20POC/NFV%20POC%20Preparation
.docx
THANK
YOU