docs/requirements/01-intro.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3 .. (c) OPNFV, Intel Corporation and others.
   4
   5 Introduction
   6 ============
   7
   8 The goal of Software Fastpath service Quality Metrics (SFQM) is to
   9 develop the utilities and libraries in `DPDK`_ to support:
  10
  11 * Measuring Telco Traffic and Performance KPIs. Including:
  12
  13   * Packet Delay Variation (by enabling TX and RX time stamping).
  14   * Packet loss (by exposing extended NIC stats).
  15
  16 * Performance Monitoring of the DPDK interfaces (by exposing
  17   extended NIC stats + collectd Plugin).
  18 * Detecting and reporting violations that can be consumed by VNFs
  19   and higher level management systems (through DPDK Keep Alive).
  20
  21 After all **the ability to measure and enforce Telco KPIs (Service
  22 assurance) in the data-plane will be mandatory for any Telco grade NFVI
  23 implementation**.
  24
  25 All developed features will be upstreamed to `DPDK`_ or other Open
  26 Source projects relevant to telemetry such as `collectd`_ and fault
  27 management such as `Monasca`_ and/or `Ceilometer`_.
  28
  29 The OPNFV project wiki can be found @ `SFQM`_
  30
  31 Problem Statement
  32 ==================
  33 The OPNFV platform (NFVI) requires functionality to:
  34
  35 * Create a low latency, high performance packet processing path (fast path)
  36   through the NFVI that VNFs can take advantage of;
  37 * Measure Telco Traffic and Performance KPIs through that fast path;
  38 * Detect and report violations that can be consumed by VNFs and higher level
  39   EMS/OSS systems
  40
  41 Examples of local measurable QoS factors for Traffic Monitoring which impact
  42 both Quality of Experience and 5’9s availability would be (using Metro Ethernet
  43 Forum Guidelines as reference):
  44
  45 * Packet loss
  46 * Packet Delay Variation
  47 * Uni-directional frame delay
  48
  49 Other KPIs such as Call drops, Call Setup Success Rate, Call Setup time etc. are
  50 measured by the VNF.
  51
  52 In addition to Traffic Monitoring, the NFVI must also support Performance
  53 Monitoring of the physical interfaces themselves (e.g. NICs), i.e. an ability to
  54 monitor and trace errors on the physical interfaces and report them.
  55
  56 All these traffic statistics for Traffic and Performance Monitoring must be
  57 measured in-service and must be capable of being reported by standard Telco
  58 mechanisms (e.g. SNMP traps), for potential enforcement actions.
  59
  60 Scope
  61 ======
  62 The output of the project will provide interfaces and functions to support
  63 monitoring of Packet Latency and Network Interfaces while the VNF is in service.
  64
  65 The DPDK interface/API will be updated to support:
  66
  67 * Exposure of NIC MAC/PHY Level Counters
  68 * Interface for Time stamp on RX
  69 * Interface for Time stamp on TX
  70
  71 Specific testing and integration will be carried out to cover:
  72
  73 * Unit/Integration Test plans: A sample application provided to demonstrate packet
  74   latency monitoring and interface monitoring
  75
  76 The following list of features and functionality will be developed:
  77
  78 * DPDK APIs and functions for latency and interface monitoring
  79 * A sample application to demonstrate usage
  80
  81 The scope of the project is limited to the DPDK APIs and a sample application to
  82 demonstrate usage.
  83
  84 .. Figure:: telcokpis_update.png
  85
  86    Architecture overview (showing provided functionality in green)
  87
  88 In the figure above, the interfaces 1, 2, 3 are implemented along with a sample
  89 application. The sample application will support monitoring of NIC
  90 counters/status and will also support measurement of packet latency using DPDK
  91 provided interfaces.
  92
  93 VNF specific processing, Traffic Monitoring, Performance Monitoring and
  94 Management Agent are out of scope. The scope is limited to Intel 10G Niantic
  95 support.
  96
  97 The Proposed MAC/PHY Interface Counters include:
  98
  99 * Packet RX
 100 * Packet TX
 101 * Packet loss
 102 * Interface errors + other stats
 103
 104 The Proposed Packet Latency Monitor include:
 105
 106 * Cycle accurate ‘stamping’ on ingress
 107 * Supports latency measurements on egress
 108
 109 Support for additional types of Network Interfaces can be added in the future.
 110
 111 Support for failover of DPDK enabled cores is also out of scope of the current
 112 proposal. However, this is an important requirement and must-have functionality
 113 for any DPDK enabled framework in the NFVI. To that end, a second phase of this
 114 project will be to implement DPDK “Keep Alive” functionality that would address
 115 this and would report to a VNF-level Failover and High Availability mechanism
 116 that would then determine what actions, including failover, may be triggered.
 117
 118 Consumption Models
 119 ===================
 120 Fig 1.1 shows how a sample application will be provided to demonstrate
 121 usage. In reality many VNFs will have an existing performance or traffic
 122 monitoring utility used to monitor VNF behavior and report statistics, counters,
 123 etc.
 124
 125 To consume the performance and traffic related information provided within the
 126 scope of this project should in most cases be a logical extension of any
 127 existing VNF performance or traffic monitoring utility, in most cases it should
 128 not require a new utility to be developed. We do not see the Software Fastpath
 129 Service Quality Metrics data as major additional effort for VNFs to consume,
 130 this project would be sympathetic to existing VNF architecture constructs. The
 131 intention is that this project represents a lower level interface for network
 132 interface monitoring to be used by higher level fault management entities (see
 133 below).
 134
 135 Allowing the Software Fastpath Service Quality Metrics data to be handled within
 136 existing VNF performance or traffic monitoring utilities also makes it simpler
 137 for overall interfacing with higher level management components in the VIM, MANO
 138 and OSS/BSS. The Software Fastpath Service Quality Metrics proposal would be
 139 complementary to the Fault Management and Maintenance project proposal
 140 (“Doctor”) which is also in flight, which addresses NFVI Fault Management
 141 support in the VIM. To that end, the project committers and contributors for the
 142 Software Fastpath Service Quality Metrics project wish to work in sync with the
 143 “Doctor” project – to facilitate this, one of the “Doctor” contributors has also
 144 been added as a contributor to the Software Fastpath Service Quality Metrics
 145 project.
 146
 147 .. _SFQM: https://wiki.opnfv.org/collaborative_development_projects/opnfv_telco_kpi_monitoring
 148 .. _DPDK: http://dpdk.org/
 149 .. _collectd: http://collectd.org/
 150 .. _Monasca: https://wiki.openstack.org/wiki/Monasca
 151 .. _Ceilometer: https://wiki.openstack.org/wiki/Telemetry