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 Problem Statement
   6 ------------------
   7 Providing carrier grade Service Assurance is critical in the network
   8 transformation to a software defined and virtualized network (NFV).
   9 Medium-/large-scale cloud environments account for between hundreds and
  10 hundreds of thousands of infrastructure systems.  It is vital to monitor
  11 systems for malfunctions that could lead to users application service
  12 disruption and promptly react to these fault events to facilitate improving
  13 overall system performance. As the size of infrastructure and virtual resources
  14 grow, so does the effort of monitoring back-ends. SFQM aims to expose as much
  15 useful information as possible off the platform so that faults and errors in
  16 the NFVI can be detected promptly and reported to the appropriate fault
  17 management entity.
  18
  19 The OPNFV platform (NFVI) requires functionality to:
  20
  21 * Create a low latency, high performance packet processing path (fast path)
  22   through the NFVI that VNFs can take advantage of;
  23 * Measure Telco Traffic and Performance KPIs through that fast path;
  24 * Detect and report violations that can be consumed by VNFs and higher level
  25   EMS/OSS systems
  26
  27 Examples of local measurable QoS factors for Traffic Monitoring which impact
  28 both Quality of Experience and five 9's availability would be (using Metro Ethernet
  29 Forum Guidelines as reference):
  30
  31 * Packet loss
  32 * Packet Delay Variation
  33 * Uni-directional frame delay
  34
  35 Other KPIs such as Call drops, Call Setup Success Rate, Call Setup time etc. are
  36 measured by the VNF.
  37
  38 In addition to Traffic Monitoring, the NFVI must also support Performance
  39 Monitoring of the physical interfaces themselves (e.g. NICs), i.e. an ability to
  40 monitor and trace errors on the physical interfaces and report them.
  41
  42 All these traffic statistics for Traffic and Performance Monitoring must be
  43 measured in-service and must be capable of being reported by standard Telco
  44 mechanisms (e.g. SNMP traps), for potential enforcement actions.
  45
  46 Barometer updated scope
  47 ------------------------
  48 The scope of the project is to provide interfaces to support monitoring of the
  49 NFVI. The project will develop plugins for telemetry frameworks to enable the
  50 collection of platform stats and events and relay gathered information to fault
  51 management applications or the VIM. The scope is limited to
  52 collecting/gathering the events and stats and relaying them to a relevant
  53 endpoint. The project will not enforce or take any actions based on the
  54 gathered information.
  55
  56 .. image: barometer_scope.png
  57
  58 Scope of SFQM
  59 ^^^^^^^^^^^^^^
  60 **NOTE:** The SFQM project has been replaced by Barometer.
  61 The output of the project will provide interfaces and functions to support
  62 monitoring of Packet Latency and Network Interfaces while the VNF is in service.
  63
  64 The DPDK interface/API will be updated to support:
  65
  66 * Exposure of NIC MAC/PHY Level Counters
  67 * Interface for Time stamp on RX
  68 * Interface for Time stamp on TX
  69 * Exposure of DPDK events
  70
  71 collectd will be updated to support the exposure of DPDK metrics and events.
  72
  73 Specific testing and integration will be carried out to cover:
  74
  75 * Unit/Integration Test plans: A sample application provided to demonstrate packet
  76   latency monitoring and interface monitoring
  77
  78 The following list of features and functionality will be developed:
  79
  80 * DPDK APIs and functions for latency and interface monitoring
  81 * A sample application to demonstrate usage
  82 * collectd plugins
  83
  84 The scope of the project involves developing the relavant DPDK APIs, OVS APIs,
  85 sample applications, as well as the utilities in collectd to export all the
  86 relavent information to a telemetry and events consumer.
  87
  88 VNF specific processing, Traffic Monitoring, Performance Monitoring and
  89 Management Agent are out of scope.
  90
  91 The Proposed Interface counters include:
  92
  93 * Packet RX
  94 * Packet TX
  95 * Packet loss
  96 * Interface errors + other stats
  97
  98 The Proposed Packet Latency Monitor include:
  99
 100 * Cycle accurate stamping on ingress
 101 * Supports latency measurements on egress
 102
 103 Support for failover of DPDK enabled cores is also out of scope of the current
 104 proposal. However, this is an important requirement and must-have functionality
 105 for any DPDK enabled framework in the NFVI. To that end, a second phase of this
 106 project will be to implement DPDK Keep Alive functionality that would address
 107 this and would report to a VNF-level Failover and High Availability mechanism
 108 that would then determine what actions, including failover, may be triggered.
 109
 110 Consumption Models
 111 ^^^^^^^^^^^^^^^^^^^
 112 In reality many VNFs will have an existing performance or traffic monitoring
 113 utility used to monitor VNF behavior and report statistics, counters, etc.
 114
 115 The consumption of performance and traffic related information/events provided
 116 by this project should be a logical extension of any existing VNF/NFVI monitoring
 117 framework. It should not require a new framework to be developed. We do not see
 118 the Barometer gathered metrics and evetns as major additional effort for
 119 monitoring frameworks to consume; this project would be sympathetic to existing
 120 monitoring frameworks. The intention is that this project represents an
 121 interface for NFVI monitoring to be used by higher level fault management
 122 entities (see below).
 123
 124 Allowing the Barometer metrics and events to be handled within existing
 125 telemetry frameoworks makes it simpler for overall interfacing with higher
 126 level management components in the VIM, MANO and OSS/BSS. The Barometer
 127 proposal would be complementary to the Doctor project, which addresses NFVI Fault
 128 Management support in the VIM, and the VES project, which addresses the
 129 integration of VNF telemetry-related data into automated VNF management
 130 systems. To that end, the project committers and contributors for the Barometer
 131 project wish to collaborate with the Doctor and VES projects to facilitate this.