docs/development/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 Barometer is the project that renames Software Fastpath service Quality Metrics
   8 (SFQM) and updates its scope which was networking centric.
   9
  10 The goal of SFQM was to develop the utilities and libraries in DPDK to
  11 support:
  12
  13 * Measuring Telco Traffic and Performance KPIs. Including:
  14
  15   * Packet Delay Variation (by enabling TX and RX time stamping).
  16   * Packet loss (by exposing extended NIC stats).
  17
  18 * Performance Monitoring of the DPDK interfaces (by exposing
  19   extended NIC stats + collectd Plugin).
  20 * Detecting and reporting violations that can be consumed by VNFs
  21   and higher level management systems (through DPDK Keep Alive).
  22
  23 With Barometer the scope is extended to monitoring the NFVI. The ability to
  24 monitor the Network Function Virtualization Infrastructure (NFVI) where VNFs
  25 are in operation will be a key part of Service Assurance within an NFV
  26 environment, in order to enforce SLAs or to detect violations, faults or
  27 degradation in the performance of NFVI resources so that events and relevant
  28 metrics are reported to higher level fault management systems.
  29 If physical appliances are going to be replaced by virtualized appliances
  30 the service levels, manageability and service assurance needs to remain
  31 consistent or improve on what is available today. As such, the NFVI needs to
  32 support the ability to monitor:
  33
  34 * Traffic monitoring and performance monitoring of the components that provide
  35   networking functionality to the VNF, including: physical interfaces, virtual
  36   switch interfaces and flows, as well as the virtual interfaces themselves and
  37   their status, etc.
  38 * Platform monitoring including: CPU, memory, load, cache, themals, fan speeds,
  39   voltages and machine check exceptions, etc.
  40
  41 All of the statistics and events gathered must be collected in-service and must
  42 be capable of being reported by standard Telco mechanisms (e.g. SNMP), for
  43 potential enforcement or correction actions. In addition, this information
  44 could be fed to analytics systems to enable failure prediction, and can also be
  45 used for intelligent workload placement.
  46
  47
  48 All developed features will be upstreamed to Open Source projects relevant to
  49 telemetry such as `collectd`_ and `Ceilometer`_.
  50
  51 The OPNFV project wiki can be found @ `Barometer`_
  52
  53 Problem Statement
  54 ==================
  55 Providing carrier grade Service Assurance is critical in the network
  56 transformation to a software defined and virtualized network (NFV).
  57 Medium-/large-scale cloud environments account for between hundreds and
  58 hundreds of thousands of infrastructure systems.  It is vital to monitor
  59 systems for malfunctions that could lead to users application service
  60 disruption and promptly react to these fault events to facilitate improving
  61 overall system performance. As the size of infrastructure and virtual resources
  62 grow, so does the effort of monitoring back-ends. SFQM aims to expose as much
  63 useful information as possible off the platform so that faults and errors in
  64 the NFVI can be detected promptly and reported to the appropriate fault
  65 management entity.
  66
  67 The OPNFV platform (NFVI) requires functionality to:
  68
  69 * Create a low latency, high performance packet processing path (fast path)
  70   through the NFVI that VNFs can take advantage of;
  71 * Measure Telco Traffic and Performance KPIs through that fast path;
  72 * Detect and report violations that can be consumed by VNFs and higher level
  73   EMS/OSS systems
  74
  75 Examples of local measurable QoS factors for Traffic Monitoring which impact
  76 both Quality of Experience and five 9's availability would be (using Metro Ethernet
  77 Forum Guidelines as reference):
  78
  79 * Packet loss
  80 * Packet Delay Variation
  81 * Uni-directional frame delay
  82
  83 Other KPIs such as Call drops, Call Setup Success Rate, Call Setup time etc. are
  84 measured by the VNF.
  85
  86 In addition to Traffic Monitoring, the NFVI must also support Performance
  87 Monitoring of the physical interfaces themselves (e.g. NICs), i.e. an ability to
  88 monitor and trace errors on the physical interfaces and report them.
  89
  90 All these traffic statistics for Traffic and Performance Monitoring must be
  91 measured in-service and must be capable of being reported by standard Telco
  92 mechanisms (e.g. SNMP traps), for potential enforcement actions.
  93
  94 Barometer updated scope
  95 =======================
  96 The scope of the project is to provide interfaces to support monitoring of the
  97 NFVI. The project will develop plugins for telemetry frameworks to enable the
  98 collection of platform stats and events and relay gathered information to fault
  99 management applications or the VIM. The scope is limited to
 100 collecting/gathering the events and stats and relaying them to a relevant
 101 endpoint. The project will not enforce or take any actions based on the
 102 gathered information.
 103
 104 .. image: barometer_scope.png
 105
 106 Scope of SFQM
 107 =============
 108 **NOTE:** The SFQM project has been replaced by Barometer.
 109 The output of the project will provide interfaces and functions to support
 110 monitoring of Packet Latency and Network Interfaces while the VNF is in service.
 111
 112 The DPDK interface/API will be updated to support:
 113
 114 * Exposure of NIC MAC/PHY Level Counters
 115 * Interface for Time stamp on RX
 116 * Interface for Time stamp on TX
 117 * Exposure of DPDK events
 118
 119 collectd will be updated to support the exposure of DPDK metrics and events.
 120
 121 Specific testing and integration will be carried out to cover:
 122
 123 * Unit/Integration Test plans: A sample application provided to demonstrate packet
 124   latency monitoring and interface monitoring
 125
 126 The following list of features and functionality will be developed:
 127
 128 * DPDK APIs and functions for latency and interface monitoring
 129 * A sample application to demonstrate usage
 130 * collectd plugins
 131
 132 The scope of the project involves developing the relavant DPDK APIs, OVS APIs,
 133 sample applications, as well as the utilities in collectd to export all the
 134 relavent information to a telemetry and events consumer.
 135
 136 VNF specific processing, Traffic Monitoring, Performance Monitoring and
 137 Management Agent are out of scope.
 138
 139 The Proposed Interface counters include:
 140
 141 * Packet RX
 142 * Packet TX
 143 * Packet loss
 144 * Interface errors + other stats
 145
 146 The Proposed Packet Latency Monitor include:
 147
 148 * Cycle accurate stamping on ingress
 149 * Supports latency measurements on egress
 150
 151 Support for failover of DPDK enabled cores is also out of scope of the current
 152 proposal. However, this is an important requirement and must-have functionality
 153 for any DPDK enabled framework in the NFVI. To that end, a second phase of this
 154 project will be to implement DPDK Keep Alive functionality that would address
 155 this and would report to a VNF-level Failover and High Availability mechanism
 156 that would then determine what actions, including failover, may be triggered.
 157
 158 Consumption Models
 159 ===================
 160 In reality many VNFs will have an existing performance or traffic monitoring
 161 utility used to monitor VNF behavior and report statistics, counters, etc.
 162
 163 The consumption of performance and traffic related information/events provided
 164 by this project should be a logical extension of any existing VNF/NFVI monitoring
 165 framework. It should not require a new framework to be developed. We do not see
 166 the Barometer gathered metrics and evetns as major additional effort for
 167 monitoring frameworks to consume; this project would be sympathetic to existing
 168 monitoring frameworks. The intention is that this project represents an
 169 interface for NFVI monitoring to be used by higher level fault management
 170 entities (see below).
 171
 172 Allowing the Barometer metrics and events to be handled within existing
 173 telemetry frameoworks makes it simpler for overall interfacing with higher
 174 level management components in the VIM, MANO and OSS/BSS. The Barometer
 175 proposal would be complementary to the Doctor project, which addresses NFVI Fault
 176 Management support in the VIM, and the VES project, which addresses the
 177 integration of VNF telemetry-related data into automated VNF management
 178 systems. To that end, the project committers and contributors for the Barometer
 179 project wish to collaborate with the Doctor and VES projects to facilitate this.
 180
 181 .. _Barometer: https://wiki.opnfv.org/display/fastpath
 182 .. _collectd: http://collectd.org/
 183 .. _Ceilometer: https://wiki.openstack.org/wiki/Telemetry