aboutsummaryrefslogtreecommitdiffstats
path: root/docs/requirements/01-intro.rst
blob: 2616f93491a284a42f2bf3ada02605bd856a1cc8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. (c) OPNFV, Intel Corporation and others.

Introduction
============

The goal of Software Fastpath service Quality Metrics (SFQM) is to
develop the utilities and libraries in `DPDK`_ to support:

* Measuring Telco Traffic and Performance KPIs. Including:

  * Packet Delay Variation (by enabling TX and RX time stamping).
  * Packet loss (by exposing extended NIC stats).

* Performance Monitoring of the DPDK interfaces (by exposing
  extended NIC stats + collectd Plugin).
* Detecting and reporting violations that can be consumed by VNFs
  and higher level management systems (through DPDK Keep Alive).

After all **the ability to measure and enforce Telco KPIs (Service
assurance) in the data-plane will be mandatory for any Telco grade NFVI
implementation**.

All developed features will be upstreamed to `DPDK`_ or other Open
Source projects relevant to telemetry such as `collectd`_ and
`Ceilometer`_.

The OPNFV project wiki can be found @ `SFQM`_

Problem Statement
==================
Providing carrier grade Service Assurance is critical in the network
transformation to a software defined and virtualized network (NFV).
Medium-/large-scale cloud environments account for between hundreds and
hundreds of thousands of infrastructure systems.  It is vital to monitor
systems for malfunctions that could lead to users application service
disruption and promptly react to these fault events to facilitate improving
overall system performance. As the size of infrastructure and virtual resources
grow, so does the effort of monitoring back-ends. SFQM aims to expose as much
useful information as possible off the platform so that faults and errors in
the NFVI can be detected promptly and reported to the appropriate fault
management entity.

The OPNFV platform (NFVI) requires functionality to:

* Create a low latency, high performance packet processing path (fast path)
  through the NFVI that VNFs can take advantage of;
* Measure Telco Traffic and Performance KPIs through that fast path;
* Detect and report violations that can be consumed by VNFs and higher level
  EMS/OSS systems

Examples of local measurable QoS factors for Traffic Monitoring which impact
both Quality of Experience and five 9's availability would be (using Metro Ethernet
Forum Guidelines as reference):

* Packet loss
* Packet Delay Variation
* Uni-directional frame delay

Other KPIs such as Call drops, Call Setup Success Rate, Call Setup time etc. are
measured by the VNF.

In addition to Traffic Monitoring, the NFVI must also support Performance
Monitoring of the physical interfaces themselves (e.g. NICs), i.e. an ability to
monitor and trace errors on the physical interfaces and report them.

All these traffic statistics for Traffic and Performance Monitoring must be
measured in-service and must be capable of being reported by standard Telco
mechanisms (e.g. SNMP traps), for potential enforcement actions.

Scope
======
The output of the project will provide interfaces and functions to support
monitoring of Packet Latency and Network Interfaces while the VNF is in service.

The DPDK interface/API will be updated to support:

* Exposure of NIC MAC/PHY Level Counters
* Interface for Time stamp on RX
* Interface for Time stamp on TX

Specific testing and integration will be carried out to cover:

* Unit/Integration Test plans: A sample application provided to demonstrate packet
  latency monitoring and interface monitoring

The following list of features and functionality will be developed:

* DPDK APIs and functions for latency and interface monitoring
* A sample application to demonstrate usage

The scope of the project is limited to the DPDK APIs and a sample application to
demonstrate usage.

.. Figure:: telcokpis_update.png

   Architecture overview (showing provided functionality in green)

In the figure above, the interfaces 1, 2, 3 are implemented along with a sample
application. The sample application will support monitoring of NIC
counters/status and will also support measurement of packet latency using DPDK
provided interfaces.

VNF specific processing, Traffic Monitoring, Performance Monitoring and
Management Agent are out of scope. The scope is limited to Intel 10G Niantic
support.

The Proposed MAC/PHY Interface Counters include:

* Packet RX
* Packet TX
* Packet loss
* Interface errors + other stats

The Proposed Packet Latency Monitor include:

* Cycle accurate ‘stamping’ on ingress
* Supports latency measurements on egress

Support for additional types of Network Interfaces can be added in the future.

Support for failover of DPDK enabled cores is also out of scope of the current
proposal. However, this is an important requirement and must-have functionality
for any DPDK enabled framework in the NFVI. To that end, a second phase of this
project will be to implement DPDK “Keep Alive” functionality that would address
this and would report to a VNF-level Failover and High Availability mechanism
that would then determine what actions, including failover, may be triggered.

Consumption Models
===================
Fig 3.1 shows how a sample application will be provided to demonstrate
usage. In reality many VNFs will have an existing performance or traffic
monitoring utility used to monitor VNF behavior and report statistics, counters,
etc.

To consume the performance and traffic related information provided within the
scope of this project should in most cases be a logical extension of any
existing VNF performance or traffic monitoring utility, in most cases it should
not require a new utility to be developed. We do not see the Software Fastpath
Service Quality Metrics data as major additional effort for VNFs to consume,
this project would be sympathetic to existing VNF architecture constructs. The
intention is that this project represents a lower level interface for network
interface monitoring to be used by higher level fault management entities (see
below).

Allowing the Software Fastpath Service Quality Metrics data to be handled within
existing VNF performance or traffic monitoring utilities also makes it simpler
for overall interfacing with higher level management components in the VIM, MANO
and OSS/BSS. The Software Fastpath Service Quality Metrics proposal would be
complementary to the Fault Management and Maintenance project proposal
(Doctor), which addresses NFVI Fault Management
support in the VIM. To that end, the project committers and contributors for the
Software Fastpath Service Quality Metrics project wish to collaborate with the
Doctor project to facilitate this.

.. _SFQM: https://wiki.opnfv.org/collaborative_development_projects/opnfv_telco_kpi_monitoring
.. _DPDK: http://dpdk.org/
.. _collectd: http://collectd.org/
.. _Ceilometer: https://wiki.openstack.org/wiki/Telemetry