NFV Orchestration: Challenges in Telecom Deployments

Shamik Mishra
OpenStack Summit, Vancouver, May 2015
Presenter
Shamik Mishra
 Senior Engineering Project Manager, Aricent

Focus Area: Management and Network Orchestration for NFV

 Identifying the requirements for NFV MANO
 Specifying extensible, Modular architecture for NFV Service Orchestrator
 Identifying possible requirements on the underlying Virtual Infrastructure Manager i.e. OpenStack

Proprietary & Confidential. © Aricent 2015 2

Agenda

 NFV Implementation Challenges

 End-to-End Service Monitoring of NFV
– Service Creation Model
– Service Aware Monitor

 Cloud-RAN use case

 Community Support

Proprietary & Confidential. © Aricent 2015 3

NFV: Quick Recap
Traditional NFV
Separate network appliance / function Each function virtualized and
for each function hosted on commodity hardware

Router GWs

Firewall MMEs

Load
IT Application
Balancer
Distribution
Switch IMS

 Dedicated hardware for each function  Hosted on commodity hardware through virtualization
 Unused computing capability  Scalable, elastic and efficient usage of resources
 Separate management systems  Possibility of unified management and orchestration
 Difficult to introduce new services rapidly of services

 Higher power consumption and requires more real-  Easily introduce new functions
estate  Cost-effective

Proprietary & Confidential. © Aricent 2015 4

 NFV Implementation Challenges
Source: Heavy Reading NFV Multi-Client Study 2014
NFV Implementation Challenges
How concerned is your company about the following technical challenges related to NFV?

Scalability of COTS Hardware

Power Consumption
Reliability of COTS hardware
Managing & Interworking various APIs
Cloud Orchestration & Management (Includes
Network functions Optimizing Resources)
Network Impact of virtualizing the media plane
virtualization is not
Managing Service failover and recovery
just porting legacy
Operations & backend integration (OSS Integration)
network functions to
commodity hardware Packet processing performance (deterministic) in data
plane
Security
KPI Impact related to media-sensitive applications (QoS,
jitter, latency)
Troubleshooting & Service Assurance
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Very concerned short term (within next 2 years) Very concerned longer term (in 2 to 5 Only slightly concerned Not concerned at all
years)

Proprietary & Confidential. © Aricent 2015 5

Challenges in Monitoring, Service Assurance and Scaling

Realizing large scale NFV deployments,

replicating & monitoring them

Simplifying networking configuration to

ensure automated service delivery
Monitoring
Service Assurance
Scaling Legacy network elements are often developed
for peak capacity and not for scaling. Also,
scaling does not necessarily depend on
infrastructure alone

Scaling one element in a chain of services may

require the need to touch / modify several other
elements (including legacy elements)

Proprietary & Confidential. © Aricent 2015 6

End-to-End Service Monitoring

Proprietary & Confidential. © Aricent 2015 7

End-to-End Service Monitoring in NFV
Orchestration & Monitoring
Visualization Actions

Service Monitoring
Service Request Transform
Aggregation

Resource Requests Monitoring Aggregation

Resource Deployment Monitoring Collection

Resource Monitoring Monitoring Generation

Proprietary & Confidential. © Aricent 2015 8

 End-to-End Service Monitoring in NFV
Challenges
VNF VNF
Example

Hypervisors
1 2

Switch
 A deployed VNF chain may contain multiple instances of
VNF application on VMs, Load Balancers, Firewalls, etc. FW LB
VNF VNF
 They network connectivity is managed by software
1’ 2’
switches
 The chain can have instances deployed across compute
nodes and clouds
 Clouds can be interconnected over VPN
Possible Monitoring Points
 SDN Controllers can create / manage the service chains

 Monitoring data also needed for debugging problems in the

Question?
network
Do we need a new and unified monitoring
 The VNFs can be from different vendors with separate model for NFV
monitoring & troubleshooting mechanisms

The health of the end-to-end chained service is necessary for the orchestrators & OSS to
ensure service continuity and to initiate automated actions

Proprietary & Confidential. © Aricent 2015 9

 End-to-End Service Monitoring in NFV
Impact to Scalability for a Service Chain

Becomes a bottleneck Becomes a bottleneck

Traffic Path Traffic Path

C D C D

B B
A Modify A
New Traffic
Path

B B
C D
New Traffic
Modify Path Modify

Scaled Node Scaled Node

Entire Subgraph scaled

This could now become a bottleneck
 While scaling an element of a service Scaling
chain, we may need to touch/modify the Orchestrators / devices who takes the decision for
other elements in the chain scaling needs to evaluate the impact on the subsequent
sub-graph
Proprietary & Confidential. © Aricent 2015 10
 End-to-End Service Monitoring in NFV
Impact of VNF States to Monitoring
Modified
Monitoring

 What is monitored also can Monitoring

MON1 MON2 (Mon A RUN) (Mon BRUN) (Mon B’RUN) (Mon CRUN) (Mon DRUN)
depend on VNF Execution States State

 There can be multiple VNF

Chain CH1 CH2 (B’,MAINT)
execution states like State
(A,RUN) (B,RUN) (C,RUN) (D,RUN)

– Install, Start, Stop, Run, Maintain

 The chain’s state is a derivative of VNF States RUN RUN MAINT RUN RUN
the individual VNF states
 We may want to monitor different
set of things as and when the
chain state changes B C D
A
 NFV Orchestrator will take actions
when the chain state changes like
reconfiguring the apps, B’
configuration etc.
Under upgrade

Proprietary & Confidential. © Aricent 2015 11

Translation of Forwarding Graph to Resource Requests
 Service Request would consist of a
Service Request - View
D – Network Forwarding Graph
– Set of Key Performance indicators (or
KPI-3 SLAs) for the service
A B C E

F
KPI-1
KPI-2 KPI-4

 The service request should get

Switch
decomposed to Resource A B
requests (example)
– Computing Resource Requests Router
D Resource
– Networking Resource requests Request(s)
– Placement Requests C View

Switch
 The KPI set gets transformed into F
parameters for the resource SDN
Controller E
requests

Proprietary & Confidential. © Aricent 2015 12

 Service Creation Model Service Request

 Service Requests are Service Orchestrator

Characterized by KPIs / SLAs
Resource Decomposition

 Decomposing Service Requests Controllers • Computing Networking /

to Resource Requests Requests Chaining
VNF Configuration • Placement Requests
– Configuration Requests Requests
– Computing Requests VNF VNF Manager SDN Controller

– Placement Requests
Resource Requests
 Decomposition is driven by the
Infrastructure
KPIs Managers
Other
Resource Networking
Resource Instantiate Manager Devices
 Service performance (adherence to
Placement
KPIs / SLAs) requires monitoring of Requests
individual Resource Requests & Scheduler /
Networking
Configuration
VNFs Placement Mgr.

 Monitoring data acquired at each Resource Reservations

layer should be “aggregated” to OpenStack Services Network
Devices
determine the service performance (Neutron, Nova, etc..)

Proprietary & Confidential. © Aricent 2015 13

End-to-End Service Monitoring in NFV
Monitor Service Chains
Service Orchestration Model and Service
Implementation Templates
Should we
standardize these
interfaces??? Service Monitoring Engine

Service-Aware Monitor

Infrastructure Infrastructure
statistics
Monitor
Application specific
parameters in a container
Compute
Compute App
Node-2
Infrastructure Node-1 3
App
monitoring data App App
2
App 4 5
Application specific
monitoring data 1

Proprietary & Confidential. © Aricent 2015 14

Service Aware Monitor
Service KPI Trend Scaling Resource Service Self Service
Alarm Analysis Decisions Reconfigure Healing Orchestrator

Monitoring Initiator & Aggregator Controllers

Infrastructure Service Aware Monitor

Monitoring
Metrics
Database NF3 NF4 NF5 AS
Collector Collector Collector Collector

Message Queue

API API API MA MA MA MA

NF3 NF4 NF5 Advanced
Storage Compute Networking
Services

Proprietary & Confidential. © Aricent 2015 15

Service Orchestration & Monitoring
Key Conclusions

• Decomposition of Service Requests to Resource Requests

• VNF state aware Monitoring initiation and collection
• Aggregation of Monitoring data
• Possible standardization of Monitoring Initiation and Collection
by VNF vendors and Open Source Community
• Service Aware Placement
• Modularity in Service Orchestrator Architecture

Proprietary & Confidential. © Aricent 2015 16

Cloud-RAN Use Case

Proprietary & Confidential. © Aricent 2015 17

Cloud RAN
System View LTE Layer-1 (Baseband
Unit) Processing

Cloud: Centralized eNB Pool

eNB1 eNB2
Antenna Site
VM1 VM2 VM1 VM2 Antenna

Layer 1
PDCP, L3 PDCP, L3
RLC, OAM RLC, OAM
MAC RRM MAC RRM
Antenna Site
Antenna
Guest Guest Guest Guest
RT Linux RT Linux Layer 1
RT Linux RT Linux

KVM

Host RT Linux

Proprietary & Confidential. © Aricent 2015 18

Cloud RAN OpenStack Orchestration
Compute
Network Compute
eNB1
S1 AP (172.16.114.124)
vEPC
RRM
GTPU (172.16.114.122)
OAM

eNB2
eNodeB 1 VM S1 AP (192.16.81.53)
eNodeB X2 AP (172.16.114.123)
L3
GTPU (192.16.81.51)

eNodeB X2 AP (192.16.81.52)
L2
Antenna Site
Guest OS eNB L2 (192.16.81.58)
Fedora Antenna
eNB L2 (172.16.114.120)
Layer 1
Host OS
Ubuntu

Proprietary & Confidential. © Aricent 2015 19

 CPU Utilization

 CPU load increases with CPU Utilization

90
throughput and number of
users scheduled 80 77
74
70
– Move non-real time MAC 70 64
scheduling out 60
58
52
 Setup 50

– 1 vCPU, 2GB Memory VMs 40

– Intel Core i3 processor 30

20

10

0
10 20 30 40 50 60
UL Throughput (Mbps)

Proprietary & Confidential. © Aricent 2015 20

Cloud RAN OpenStack Orchestration
Key Observations

 Packet Buffering / loss. Solved through PCI pass-through approaches

 Live VM migration of L2 Virtual Machine is a challenge, as MAC scheduler requires 1ms
of processing time
 Scaling: More eNBs realized through launching more eNB VNFs
– If eNB mapped to 3 sectors, L3 layer can be common
– If single S1 interface required for all eNBs then scaling is limited

 Scaling: CPU load increases with throughput and number of users scheduled
– Move non-real time MAC scheduling out

Proprietary & Confidential. © Aricent 2015 21

Community Support

Proprietary & Confidential. © Aricent 2015 22

Possible Community Actions
Switch-as-a-Service & Port Mirroring

 The tenant today never has any visibility into  Port mirroring is a key enabler for efficient NFV
its switch which connects the VMs of the troubleshooting and monitoring
tenant (with OVS)  Tenant should be able to mirror a port to debug
 In the real world, the user controls its own from the traffic exchanged between two VNFs
switch  Neutron API may need to be developed to
 Full control of its own switch would give initiate and terminate port mirroring by tenants
possibilities like
– Flexibility in defining service chains through SDN
controller by the tenant
– Defining custom monitoring
– Same network visibility as a dedicated switch
– Security settings like MAC based policies

Proprietary & Confidential. © Aricent 2015 23

Possible Community Actions
SIP Load Balancing as a Service

 IMS is now widely used by operators to Reference: SIP Load-Balancing-as-a-Service

provide packet-switched voice and other (LBaas). David Waiting
multimedia services to customers. https://etherpad.openstack.org/p/telcowg-
 SIP (Session Initiation Protocol) is used in IMS usecase-SIP_LBaaS.
to setup and teardown real-time voice and
video calls.
 Huge SIP traffic needs to be balanced across a
group of IMS nodes to ensure scalability and
reliability of Telco IMS services.
 To ensure a robust and scalable virtualized
IMS network, SIP LBaaS would be a much
needed service in OpenStack.

Proprietary & Confidential. © Aricent 2015 24

Thank you.
Headquarters
303 Twin Dolphin Drive
6th Floor
Redwood City, CA 94065
USA
Tel: +1 650 632 4310
Fax: +1 650 551 9901

Proprietary & Confidential. © Aricent 2015