This panel will discuss challenges and solutions related to service assurance for network functions virtualization (NFV). Key challenges include correlating faults between the virtualized network function (VNF) and underlying hardware layers, automatic onboarding of assurance policies for new services, and accurate service impact analysis across layers. Solutions proposed are developing a unified data model for hybrid networks, tight integration with orchestrators, advanced service impact analysis, and consolidating NFV infrastructure and VNF operation under one team. Closed-loop automation is difficult to achieve due to challenges with reliable inventory, topology exposure, and lack of standards around policy encapsulation.

1. PANEL III:
SERVICE ASSURANCE FOR NFV

2. Panel
Mark Newman
Chief Analyst
TMF
James Crawshaw
Senior Analyst
Heavy Reading
Laszlo Bojtos
Solution Architect
Zenoss
Ihab Mahna
Solution Architect
EXFO
Yuval Stein
AVP Product Mgmt
Service Assurance
TEOCO
Ignacio Mas
Senior Expert in
Programmable Networks
Ericsson

3. Outline
• Operators are currently focused on the near-term challenges of NFV, such
as onboarding VNFs and interoperability
• However, they need to start preparing for the longer-term challenge of
enabling service assurance
• SA is particularly challenging for services delivered over a hybrid of physical
and virtual network functions
• Detailed end-to-end service paths will be needed to relate service
measurements across VNFs and physical devices.
• Problems at the hardware layer (NFVi) will impact the software layer
(VNFs) leading to a multiplicity of alarms and the need for new correlations
to be mapped out.
• This panel will discuss service assurance for NFV and how to deliver on the
promise of closed-loop automation.

4. Verizon – Service Assurance for Hybrid
• Service Assurance
complexity is higher
• Automated backup?
OpenStack snapshots
• Self-healing? Not if the
license is tied to a VM ID, a
security certificate is
required or there have
been config changes since
last snapshot
• Auto scaling? Depends on
VNF support, licensing and
commercial policy Source: Verizon

5. NFV a l’Orange
Source: Adapted by Heavy Reading from Future OSS whitepaper, Orange.

6. NFV Assurance a l’Orange
Operations module:
• Dynamic fault and performance management (VNF/PNF) – intelligent fault diagnosis, localization and impact
analysis using alarm pattern and service impact libraries
• Service desk and workforce management – analytics to set rules to manage tickets and work orders
• Test & diagnosis – to support policy verification, incident resolution and test end-to-end service chain on design or
instantiation.
• Incident management – using dynamic applications and analytics
• Problem management – resolving remaining issues through higher level human skills and cross-department
cooperation
Visualization module:
• Flexible view – if problems cannot be resolved autonomously they need to be represented in an operations view
showing the status of network, fulfillment orders and transactions
• Presentation configuration – to enable different types of view (e.g. dynamic inventory) with required granularity
• Data orientation – data model to support metrics, events, and configuration data
• Analytics notebooks – to share analysis across multiple parties for cooperation

7. Must correlate between NVFI and VNFM
• How can we tell if a fault is originating in the VNF itself or in the
underlying hardware?
• Shannon and Yates write: “An issue at the hardware layer (cloud
servers) that impacts the software layer (VNF) will alarm at both
layers. Without appropriate intelligence and automation, the
alarming on the hardware and software layers could result in both
the hardware operations team and team managing the VNF to
simultaneously respond to the issues reported and investigate the
root cause in parallel.”

8. OSM Release 3 Service Assurance
• Monitoring module, which is
described as experimental,
can correlate telemetry [CPU
utilization, read latency, etc.]
related to the VMs and VNFs
to the relevant network
services
• If a VM fails and triggers an
alarm, you don't get a
duplicate alarm on the VNFs
running on that VM, so you
don't waste the time of the
team managing the VNFs.
Only the NFVi team need
respond.
Source: ETSI

9. Meeting the Challenges of NFV Assurance - 1
Challenges across all layers Solution
Analytics and Reporting for Hybrid Networks
(both PNFs & VNFs)
A unified data model for hybrid networks to abstract any NF
Accurate Root-Cause Analysis in a
dynamically changed topology
Use algorithms that can pinpoint service and network issues
in near real-time to trigger healing as part of closed-loops

10. Meeting the Challenges of NFV Assurance - 2
Service Management challenges Solution
Automatic onboarding of Assurance
definitions (policies) for new services
Tight Integration with the E2E Orchestrator to be notified on
Service creation and changes (TOSCA)
Accurate Service Impact analysis among
layers (Services, VNFs). To be used as part of
closed-loops.
• Well updated Service-Resource Data Model
• Integration with the E2E Orchestrator to be notified on
Service creation and changes
• Advanced Service Impact Analysis
Integration with legacy OSS e.g. ticketing
(Resource and Service Management)
Open north-bound APIs from SA system
Monitoring SLAs and OLAs in a multi-
operator, multi-vendor business context
(Partner Management)
• Integration with the E2E Orchestrator to be notified on
dynamic changes in resources or services related to
partner management (SLA & Thresholding interfaces).
• Use strong thresholding capabilities

11. Meeting the Challenges of NFV Assurance - 3
VNF and Virtual Infrastructure Challenges Solution
VNFs are not aware of the NFVI
dependencies (performance/availability of
underlying compute, storage, networking,
hypervisor, OS).
Consolidate the operation of NFV infrastructure and VNFs
under one team
Alarms on NVFI triggers alarms on VNFM SA system must correlate between NVFI and VNFM
The NFVI that supports VNFs changes
dynamically
SA system must keep up with these changes
Difficulty onboarding new VNFs or NFVI SA system must support multiple protocols (SNMP, syslog,
XML, Netconf), and facilitate integration of vendor specific
APIs
Integration with NFVO SA system must receive service models, inventory and other
data from NFVO and automatically send remediation
requests based on problems it identifies

12. Closed loop assurance
• Lessons learned from early trials indicate that this space is very challenging
for COTS type offerings, with substantial customer adaptation required.
• A key challenge to hybrid orchestration has turned out to be a lack of
reliable inventory information exposing the underlying topology. Siloed
inventory remains a problem most operators have not invested in solving.
• Recent work in the MEF, on TAPI and topology engine concepts is
promising. The concept of the network as an inventory (from years back),
is now becoming more viable with the virtualization of the network, and
the advanced integration capabilities in the virtualized network functions
are enabling this.
• Policy is perhaps the largest issue to solve for Closed Loop Assurance. No
standard way to encapsulate and expose rules is a barrier to
interoperability between responsibility domains, and any master
orchestrator trying to implement closed loop network actions.